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Summary 


At  the  heart  of  the  full  ELLA  language  are  a  set  of  Core  constructs  into  which  any  ELLA 
description  can  be  transformed.  This  document  describes  a  set  of  forma]  transformation 
rules  which  map  these  Core  constructs  into  a  set  of  data  structures.  These  transformation 
rules  define  the  static  semantics  of  the  language.  Examples  are  given  of  circuits  which 
are  translated  from  the  full  language  into  ELLA’s  Core  and  of  Core  circuits  which  are 
translated  via  the  formal  transformation  system  into  a  set  of  data  structures. 


Crown  Copyright  ©Controller  HMSO,  London,  1991. 


91-14824 


029 


INTENTIONALLY  BLANK 


ELLA  Static  Semantics 


1 


Contents 

1  Introduction  5 

2  Core  ELLA  7 

2.1  Introduction .  7 

2.2  Software  Transformational  System .  7 

2.3  ELLA  Hierarchical  Definition .  9 

2.3.1  Excluded  Constructs .  9 

2.3.2  Core  ELLA  Constructs  .  10 

2.3.3  Transformable  Constructs . 12 

2.4  Core  ELLA  Composite  Syntax . 15 

2.4.1  Basic  Notation .  15 

2.4.2  Syntactic  Categories .  15 

2.4.3  Enumerated  Values .  16 

2.4.4  Types .  16 

2.4.5  Constants .  16 

2.4.6  Constant  Sets . 17 

2.4.7  Units  .  17 

2.4.8  Closedclause  .  18 

2.4.9  Function  Body .  18 

2.4.10  Type  Declarations .  19 

2.4.11  Function  Declarations .  19 

2.4.12  Closure .  19 

2.5  Well  Formedness  of  Core  ELLA . 20 

3  Kernel  ELLA  23 

3.1  Introduction . 23 

3.2  Conventions . 23 

3.2.1  Links  to  VDM . 24 

3.3  Kernel  Data  Structure . 25 

3.3.1  Enumerated  Values . 25 

3.3.2  Types . 25 

3.3.3  Constants . 25 

3.3.4  Constant  Sets . 26 


2 


Contents 


3.3.5  Units  . 26 

3.3.6  Function  Declarations . 26 

3.3.7  Type  Declarations . 27 

3.3.8  Closure . 27 

3.4  Environments  and  Signatures . 27 

3.4.1  Transformation  Environment . 27 

3.4.2  Built-In  Operator  Environment . 29 

3.4.3  Signatures . 29 

3.4.4  Scopes . 30 

3.4.5  Join  Checks . 31 

3.4.6  Two  Value  Types . 31 

3.4.7  Check  names . 32 

3.4.8  Adding  Names  to  an  Environment . 32 

3.4.9  Finding  Names  in  an  Environment . 34 

3.4.10  Removing  Type  Aliasing . 36 

3.4.11  Type  Checking . 36 

3.4.12  Concatenation . 37 

3.4.13  Character  Check . 37 

3.4.14  Type  Indexing . 38 

3.4.15  Reform . 38 

3.4.16  Local  Type  Checking . 38 

3.4.17  Constructing  Tuples . 39 

3.4.18  Case  Disjointness . 39 

3.5  Formal  Transformation  System . 40 

3.5.1  Enumerated  Values . 40 

3.5.2  Types . 41 

3.5.3  Constants . 42 

3.5.4  Constant  Sets . 43 

3.5.5  Units  . 44 

3.5.6  Closedclause  . 46 

3.5.7  Built-In  Functions . 48 

3.5.8  Type  Declarations . 49 

3.5.9  Function  Declarations . 50 


ELLA  Static  Semantics 


3 


3.5.10  Closure . 51 

3.6  Extracting  the  Type  of  a  Kernel  Structure . 51 

3.6.1  Constant  Type  Value  . 51 

3.6.2  Constant  Set  Type  Value . 52 

3.6.3  Unit  Type  Value . 52 

3.7  A  Formal  Transformation  Example . 53 

3.7.1  Type  Declaration . 53 

3.7.2  Function  Declaration . 55 

3.7.3  Function  Declaration  with  Scoping . 58 

3.7.4  The  Kernel  Closure  . 66 

4  Conclusions  69 

5  Acknowledgements  69 

A  Glossary  of  Symbols  71 

B  ELLA  Composite  Syntax  73 

B.l  Basic  Notation .  73 

B.2  Syntactic  Categories .  73 

B. 3  Syntactic  Definitions .  74 

C  Core  ELLA  Composite  Syntax  83 

C. l  Basic  Notation . 83 

C.2  Syntactic  Categories . 83 

C. 3  Syntactic  Definitions . 84 

D  Kernel  of  ELLA  Data  Structure  87 

D. l  Conventions . 87 

D. 2  Kernel  Data  Structure . 87 

E  FIFO  Example  91 

E. l  High  Level  Description . 91 

E. 2  Transformed  Description  . 91 

F  Three  Pump  Controller  95 

F. l  Introduction . 95 


4 


Concents 


F.2  High  Level  Description . 95 

F.3  Medium  Level  Description . 96 

F.4  Low  Level  Description . 98 


References 


101 


ELLA  Static  Semantics 


5 


1  Introduction 

The  ELLATAf  system  is  an  integrated  hardware  design  tool-set,  which  comprises  the  ELLA  lan¬ 
guage  compiler,  the  ELLA  Applications  Support  Environment  (EASE),  the  ELLA  simulator, 
and  the  ELLANET  procedural  interface  [Com90a][Com90b][Com90c][Com90d].  The  language 
is  used  to  describe  hardware  at  all  stages  in  the  VLSI  design  cycle,  from  the  earliest  architectural 
concepts  to  the  full  implementation  at  gate  level.  The  ELLA  system  was  originally  developed 
at  the  Royal  Signals  and  Radar  Establishment  in  Malvern,  UK.  and  is  now  being  enhanced  in 
collaboration  with  Computer  General  Electronic  Design  (ED)  of  Chippenham.  ELLA  is  the 
de-facto  standard  high-level  VLSI  design  language  in  the  UK,  and  is  marketed  by  ED.  In  1989 
ELLA  won  a  Queens  Award  for  Technological  Achievement. 


ELLA  describes  a  circuit  as  a  hierarchy  of  interconnected  nodes  or  networks.  Networks  can  be 
described  using  an  explicit  netlist  style  or  an  implicit  functional  form.  The  language  has  no 
predefined  signals  and  therefore  a  user  must  define  the  most  appropriate  form  of  abstract  data 
type  for  the  design  under  consideration.  The  behaviour  of  the  network  is  defined  in  terms  of 
leaf  nodes  or  expressions.  Many  of  the  higher  level  syntactic  constructs  in  the  language  are 
directly  replaceable  by  a  series  of  lower  level  ones.  This  facility  means  that  high  level  abstract 
behavioural  designs  can  be  transformed  down  into  lower  level  circuits  ready  for  acceptance  by 
low  level  back  end  tools.  Thus  users  interested  in  synthesis  and/or  verification  can  maintain  a 
top  level  description  of  a  circuit  whilst  experimenting  with  different  transformations  in  order 
to  get  the  optimum  low  level  design. 


ELLA  has  been  developing  at  RSRE  for  the  past  ten  years.  Throughout  this  development  the 
original  language  [MPT85]  has  been  built  upon,  with  many  of  the  new  features  transformable 
into  the  original  language  [WMW+89][MPW87].  New  constructs  have  also  been  added  to  the 
set  of  original  core  constructs,  for  example  ELLA  V4  has  the  ability  to  model  real  arithmetic  as 
well  as  bit  string  manipulation  [HPC+90].  This  is  possible  by  the  introduction  of  a  new  form  of 
data  type  and  a  set  of  Built  in  Operators  (BIOPs).  The  language  is  currently  being  enhanced 
under  several  collaborative  projects,  and  many  of  the  new  language  features  are  described  in 
[HWM90b][HWM9l].  This  work  will  culminate  in  the  release  of  ELLA  V6.  Work  described 
in  [HWM90b]  comprises  the  introduction  of  named  output  signals,  multiple  declarations  and 
a  greatly  enriched  mechanism  for  joining  up  circuits.  Memorandum  [HWM90b]  also  describes 
enhancements  to  the  timing  model  for  allowing  multi-rate  circuits,  a  formal  definition  of  which 
is  given  in  [HWM90a].  The  memorandum  [HWM91]  describes  the  rationalisation  to  the  func¬ 
tion  type  mechanism.  The  ability  to  ‘link-in’  non-ELLA  code,  such  as  microprocessor  models, 
and  provide  powerful  parameterisable  functions  (these  take  function  instantiat ions /templates 
as  parameters)  increases  the  languages  flexibility.  These  enhancements  will  be  described  in 
[DCT]  along  with  most  of  the  recent  language  enhancements. 


In  this  report  we  give  the  formal  definition  of  the  static  semantics  of  ELLA’s  Core  constructs. 
We  start  in  section  2  by  des jibing  the  set  of  constructs  which  form  the  Core  of  the  language 
and  then  indicate  how,  by  the  means  of  a  set  of  software  and  syntactic  transformations,  any 
circuit  can  be  mapped  into  a  set  of  Core  constructs.  Although  Core  ELLA  is  a  simpler  lan¬ 
guage  than  the  full  language  it  still  needs  to  address  the  problems  of  scopes  and  type  checking. 
To  this  end  a  set  of  data  structures  have  been  defined  which  removes  such  obstacles.  This  is 
achieved  by  introducing  an  environment  which  provides  every  identifier  with  a  unique  number. 
Thus  scopes  and  types  are  effectively  flattened  so  that  the  environment  can  identify  anything 
by  its  unique  representation.  The  set  of  data  structures  is  defined  to  be  the  Kernel  of  ELLA 
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and  it  is  possible  to  map  any  description  in  the  full  language  down  onto  structures  in  the 
Kernel.  The  definition  of  the  Kernel  along  with  the  formal  transformations  to  go  from  Core 
ELLA  to  the  Kernel  are  given  in  section  3.  Since  the  Kernel  is  a  set  of  data  structures  all  the 
information  it  holds  cannot  easily  be  expressed  in  terms  of  a  concrete  syntax.  However  it  is  pos¬ 
sible  to  consider  subsets  of  the  Kernel  for  which  a  syntax  is  possible,  see  for  example  [BGL+9l]. 


The  work  described  in  this  report  has  been  carried  out  for  an  IED  (Information  Engineering 
Directorate)  project  on  “Formal  Verification  Support  for  ELLA”  in  collaboration  with  Manch¬ 
ester  University  Computer  Science  Department  and  Harlequin  Ltd.  of  Cambridge.  The  aims  of 
the  Kernel  are  therefore  that  it  should  provide  a  simple  system  for  mathematical  manipulation 
and  that  it  should  interface  simply  with  the  verification  work  of  the  IED  project,  which  is  being 
carried  out  by  Manchester  University  Computer  Science  Department. 
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2  Core  ELLA 

2.1  Introduction 

In  this  section  we  give  the  definition  of  Core  ELLA.  Core  ELLA  is  a  subset  of  the  complete 
language  which  is  small  enough  for  formal  definition  and  manipulation,  yet  large  enough  to 
retain  the  character  and  flavour  of  the  complete  language.  In  essence  Core  ELLA  is  that  part 
of  the  language  which  is  arrived  at  from  a  description  in  the  full  language  by  applying  a  set 
of  software  transformations  and/or  a  set  of  formal  syntactic  transformations.  This  is  possible 
since  ELLA’s  evolution  has,  to  a  large  extent,  occurred  by  defining  the  semantics  of  the  more 
sophisticated  syntactic  constructs  in  terms  of  the  semantics  of  more  primitive  constructs.  The 
language  has  thus  been  able  to  retain  a  small  number  of  primitive  orthogonal  constructs  as  its 
nucleus,  with  the  complex  constructs  transforming  onto  this  nucleus.  Thus  Core  ELLA,  though 
much  simpler  than  the  complete  language,  contains  the  essence  of  the  complete  language. 

We  start  by  giving  a  brief  outline  of  the  software  transformational  system  and  then  in  the 
following  subsection  subdivide  the  full  language  into  different  classes  to  facilitate  the  definition 
of  Core  ELLA. 


2.2  Software  Transformational  System 

The  Software  Transformational  System  is  a  collection  of  software  procedures  which  take  high 
level  language  constructs  and  transform  them  into  lower  level  constructs.  The  transformed  cir¬ 
cuit  description  can  then  be  viewed  by  printing  the  result  in  ELLA  textual  form.  This  Transfor¬ 
mational  System  has  allowed  the  incorporation  into  the  language  of  a  number  of  sophisticated 
syntactic  constructs  by  simply  relating  their  semantic  interpretation  to  already  existing  con¬ 
structs.  The  present  set  of  transforms  can  be  broadly  categorised  into  the  following,  macro, 
sequence,  step,  function-type,  timescale  and  imports. 

The  macro  transformation  replaces  calls  of  macros  by  the  appropriate  function  instance  with 
parameters  substituted.  It  also  transforms  out  replicators  and  evaluates  constant  and  integer 
expressions.  Although  it  is  possible  to  separate  the  macro  and  replicator  transforms  into  two 
distinct  transforms  they  have  been  kept  together  because  replicators  are  a  particular  form 
of  macro.  The  sequence  transformation  replaces  all  the  sequence  constructs  by  appropriate 
lets,  makes,  joins  and  unit  delays.  The  step  transformation  replaces  all  the  multiple  lets, 
makes  and  complex  join  statements  by  occurrences  of  their  simpler  versions.  The  function- 
type  transformation  removes  all  occurrences  of  function  type  signals,  for  example  a  single 
bidirectional  wire  is  replaced  by  two  distinct  wires.  Use  of  timescale  transforms  the  hierarchical 
retiming  constructs  (i.e.  FASTER  and  SLOWER)  into  functions  with  delays  and  a  sample- 
and-hold  construct,  whilst  imports  substitutes  the  bodies  of  imported  functions  into  their 
appropriate  calling  function. 

As  a  simple  example  of  the  transformational  system  consider  the  following  Set /Reset  Latch 
which  is  described  using  ELLA's  sequential  constructs 
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TYPE  bool  *  IEW  (  t  I  f  ) . 

FI  SR.LATCH  =  (bool:  set  reset)  -> 
(  SEQ 

PVAR  q  (l.t); 

CASE  (set,  reset) 

OF  (t,t)l(i,t):  q  :  =  (i ,  t), 
(t,  1)  :  q  :=  (t,  1 ) , 

(f.  1)  : 

ESAC; 

OUTPUT  q 


(2]  bool: 

•  create  and  initialise  state  variable  • 
i  state  variable  assigned  nee  value  • 

•  state  variable  retains  previous  value  t 

•  output  nes  value  ol  state  variable  * 


When  this  is  passed  through  the  transformations  the  sequence  constructs  are  replaced  by  equiv¬ 
alent  parallel  constructs  to  produce  the  following  circuit 

FI  Fl.DELAY  =  ((  bool,  bool  ))  ->  (  bool,  bool  ) : DELAY ((  1,  t  ),  1  ). 

FI  SR.LATCH  =  (  bool:  set  reset  )  ->  [  2  ]bool: 

(  HAKE  Fl.DELAY  :  s4q. 

LET  q  *  CASE  (  set,  reset  ) 

OF  (  t.  t  )  1  (l,t):  (  LET  s6q  =  ( 

OUTPUT  s6q 

). 

(  t,  1  )  :  (  LET  s7q  =  ( 

OUTPUT  s7q 

). 

(1,1)  :  s4q 

ELSE  s4q 
ESAC. 

JOII  q  ->  s4q. 

OUTPUT  q 

)• 

where  names  with  an  ‘s’  followed  by  a  number  are  generated  by  the  transformation  process.  It 
should  be  noted  that  the  code  generated  has  been  designed  for  simulation  purposes  rather  than 
readability  and  conciseness. 

The  amount  of  code  generated  by  the  transformations  depends  on  how  concisely  the  higher  level 
description  has  been  written.  For  example  the  following  FIFO  stack  expands  to  over  100  lines 
of  code  when  passed  through  the  transformations.  The  complete  transformed  design  is  given  in 
appendix  E. 


1,  t  ). 

t,  1  ). 
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TYPE  bool  «  SEW  (  t  I  f  I  x  ), 
int  =  IEW  i/(0. .100) . 

MAC  FIFO  {1ST  size}  s  (int:  data.in,  bool:  shift. in,  bool:  shift.out) 

->  (int,  bool): 

(SEQ 

PVAR  fifo  [siz«](i/0,  f); 

CASE  shift.out 

OF  t  :  fifo  :=  fifo[2. .size]  COSC  (i/0,  f) 

ESAC; 


VAR  entered  :=  f; 

CASE  shift.in 

OF  t  :  [1ST  i  =  1.. size-1] 

CASE  (entered,  fifo[i][2]) 

OF  (f,f)  :  (  fifo[i]  :=  (data.in,  t); 
entered  :=  t 

) 

ESAC 


ESAC; 


OUTPUT  (fifo[l][l],  entered) 

). 


FB  FIF0.9  =  (int:  data.in,  bool:  shift.in,  bool:  shift.out)  ->  (int,  bool): 
FIFO  {9}  (data.in,  shift.in.  shift.out). 


It  is  possible  to  synthesise  ELLA  circuits  down  to  gate  level  by  using  one  of  the  currently  avail¬ 
able  synthesis  systems,  e.g.  GATEMAP  (Pitt88j.  Appendix  F  gives  an  example  of  a  circuit 
which  has  passed  through  the  GATEMAP  system. 


In  the  next  section  we  split  the  full  language  into  three  classes  in  order  to  aid  the  definition  of 
the  language  features  for  Core  ELLA. 


2.3  ELLA  Hierarchical  Definition 

For  the  purposes  of  this  report  the  full  language  will  be  subdivided  into  three  classes.  The 
first  of  these  classes  contains  those  constructs  for  which  a  formal  semantic  definition  will  not 
be  required 


2.3.1  Excluded  Constructs 

There  are  five  language  constructs  which  come  into  this  class  and  they  each  have  a  different 
reason  for  being  selected 

•  ARITH  (being  superseded  by  BIOPs) 

•  FNSET  (being  superseded  by  extensions  to  function  types) 
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•  Attributes  (these  provide  an  interface  to  external  software) 

•  ALIEN  (Linkage  to  non-ELLA  code) 

•  Machine  Dependent  BIOPs  (Because  of  machine  dependency) 

It  is  probable  that  all  the  operations  which  can  be  performed  with  ARITH  statements  will 
be  achievable  through  the  BIOP  mechanism  and  therefore  there  is  no  loss  of  functionality  by 
including  ARITH  in  this  class  of  constructs.  It  should  be  noted  that  BIOP’s  also  provide  a 
more  rigorous  definition  of  arithmetic  operations. 

The  function  type  extension  [HWM91]  allows  function  type  signals  in  the  output  part  of  a  func¬ 
tion  specification,  this  means  that  function  sets  can  be  represented  by  functions  with  function 
type  output  signals  and  therefore  function  sets  need  not  be  considered  as  a  separate  case. 

The  remaining  three  constructs  either  describe  linkage  to  non-ELLA  language  code  or  code 
which  depends  on  the  platform  on  which  ELLA  is  installed. 


2.3.2  Core  ELLA  Constructs 

This  second  class  contains  those  constructs  which  will  form  Core  ELLA.  It  would  have  been 
possible  to  reduce  the  size  of  Core  ELLA  even  further  if  functions  had  been  transformed  out 
and  only  basic  enumerated  types  allowed.  However  this  would  have  left  only  a  single  large 
network  of  nodes  for  any  context  and  such  a  network,  whilst  suitable  for  a  simulator,  would 
have  been  very  unhelpful  for  a  user  of  the  IED  projects’  verification  environment.  In  particular 
if  a  user  experimented  with  rules  built  up  from  the  semantics  there  would  be  a  problem  in 
relating  information  back  to  the  user,  such  as  what  part  of  the  original  ELLA  circuit  was  being 
analysed. 

All  the  basic  language  primitives  have  been  incorporated  including  the  latest  additions  to  the 
ELLA  language  i.e.  those  from  the  numerics  package  [HPC+90],  retiming  [HWM90a]  and 
BIOP’s  [Tai88a].  Rows  have  been  included  since  they  provide  useful  functionality  and  they 
complement  STRING’S.  Constant,  integer  and  macro  declarations  are  not  included  since  they 
are  evaluated  before  a  circuit  is  assembled,  via  the  software  transformation  system.  Only 
single  makes,  joins  and  lets  are  necessary  since  the  multiple  version  of  these  constructs  can  be 
transformed  into  the  simple  versions. 


2.3.2. 1  Types  The  complete  ELLA  typing  system  has  been  included,  i.e. 

•  •  Enumerated  declaration  (e.g.  bool,  int,  char  ) 

•  Associated  declaration  (e.g.  tag&bool  ) 

•  Unknown  value  (e.g.  ?type  ) 

•  Collaterals  (e.g.  (bool, bool)  ) 

•  Rows  (e.g.  [3]bool  ) 

•  STRINGS  (of  ELLA  characters  e.g.  STRING[3]chars  ) 

•  Void  (e.g.  ()  ) 
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Thus  all  forms  of  enumerated  types  including  ELLA  integers  and  ELLA  characters  are  available 
in  Core  ELLA.  All  possible  forms  of  structured  types  are  also  available  as  well  as  an  ELLA  un¬ 
known  value  corresponding  to  each  type.  The  ‘Void’  type  has  also  been  included  and  represents 
a  non- value  carrying  type.  Such  a  type  can  be  used,  for  example,  when  a  function  does  not 
require  either  an  input  or  an  output  signal,  as  in  the  case  of  a  test  harness. 


2.S.2.2  Constants  and  Integers  Within  Core  ELLA  all  constants  and  integers  will  be 
given  as  explicit  basic  values.  Since  constant  and  integer  expressions  are  always  defined  statically 
in  ELLA  and  the  macro  transformation  can  simplify  them  to  basic  values  this  is  not  a  severe 
limitation.  Hence  the  type  of  expressions  available  are 

•  Constant  enumerated  values  (e.g.  true,  i/2,  c'z) 

•  Constant  type  names  (e.g.  bool) 

•  Constant  associated  type  values  (e.g.  tag&true) 

•  Integer  values  (e.g.  5) 


2.3. 2.3  Primitive  Nodes  All  the  primitive  nodes  of  ELLA  are  included  in  Core  ELLA. 
These  are 

•  CASE  with  no  ‘ELSEOF’  (e.g.  CASE  bool  OF  t:f  ELSE  x  ESAC  ) 

•  REPLACE  (e.g.  replace  an  element  of  an  array  ) 

•  DELAY  (e.g.  Ambiguity  Delay  primitive  ) 

•  IDELAY  (e.g.  Inertial  Delay  primitive  ) 

•  RAM  (e.g.  Multiple-element  read/write  memory:  RAM([256]i/l)  ). 

•  SAMPLE  (e.g.  the  SAMPLE-and-hold  timing  primitive  used  for  retiming  ) 

•  BIOP  (e.g.  machine  independent  Built-in-Operators) 

It  is  necessary  to  include  all  these  primitive  nodes  of  ELLA  since  they  are  not  easily  transformed. 
The  CASE  statement  has  been  restricted  to  exclude  the  ELSEOF  alternative  since  the  ELSEOF 
part  can  be  transformed  out  (see  section  2.3. 3. 2).  The  new  REPLACE  construct  allows  arrays 
to  have  one  of  its  fields  replaced  by  the  output  from  a  value  delivering  expression.  The  two  forms 
of  Delays  are  needed  since  they  are  fundamental  in  providing  ELLA’s  functionality.  The  new 
sample-and-hold  primitive  has  been  included  so  that  designs  with  retiming  can  be  transformed 
into  Core  ELLA.  Only  those  BIOP’s  which  are  machine  independent  are  included  here. 


2.S.2.4  Functions  Function  declarations  have  been  retained  within  Core  ELLA  in  order  to 
preserve  the  modularity  of  a  design.  It  would  be  possible  to  transform  out  all  functions  within 
a  context  but  this  would  leave  only  a  flattened  circuit.  Most  designers  use  functions  in  order 
to  partition  designs  into  more  manageable  units  and  this  feature  is  felt  to  be  desirable  for  Core 
ELLA.  By  allowing  functions  it  also  means  that  operations  on  them  can  be  included  e.g.  make, 
join.  The  complete  list  of  function  related  constructs  is 


•  Functions  Declarations 
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•  MAKE  (e.g.  MAKE  AND:  and.  ) 

•  Implicit  Monadic  Function  Calls  (e.g.  AND(inl,in2)  ) 

•  JOIN  (e.g.  JOIN  ...  — *  name) 

•  LET  (e.g.  LET  name  =  ...) 

•  BEGIN.. .OUTPUT.. .END  clause 

•  Locally  declared  function  and  type  declarations 

Only  monadic  function  calls  have  been  included  since  a  dyadic  call  is  just  another  way  of  repre¬ 
senting  a  monadic  function  with  two  inputs.  Both  the  JOIN  and  LET  statements  are  restricted 
to  the  ELLA  V4  syntax  [Com90a]  since  the  enhancements  recently  carried  out  [HWM90b]  can 
be  transformed  into  that  form.  The  BEGIN. ..END  clauses  is  included  in  order  to  allow  the 
LET,  JOIN,  MAKE  statements  to  be  used,  as  well  as  to  declare  local  functions  and  types. 


2.3. 2.5  Signal  Structuring  and  Extraction  Signals  within  a  Core  ELLA  program  will 
need  to  be  structured,  or  extracted,  from  other  signals.  For  this  reason  the  following  have  been 
included  in  Core  ELLA. 

•  Indexing  (e.g.  id[2]  ) 

•  Trimming  (e.g.  id[l..6]  ) 

•  Dynamic  Indexing  (e.g.  indexing  an  expression  by  a  signal  value) 

•  CONC  (concatenation) 

•  REFORM  (of  signal  groups) 

•  Associated  type  constructs  (i.e.  ‘//’  and  *&’) 

•  Rows/STRINGS  of  value  delivering  clauses 

•  Collaterals  of  value  delivering  clauses 

Indexing,  dynamic  indexing  and  trimming  enables  components  of  structures  to  be  extracted 
and  CONC  enables  components  to  be  combined.  REFORM  is  a  means  by  which  a  set  of 
signals  can  be  regrouped  to  form  a  different  combination  e.g.  (bool,[3]bool)  can  be  reformed  to 
([2]bool,[2]bool).  The  two  associated  type  constructors  are  needed  since  there  is  no  other  way 
for  creating  and  extracting  data  from  an  associated  type.  The  last  two  items  are  ways  in  which 
structures  of  value  delivering  clauses  can  be  constructed. 


2.3.3  IVansformable  Constructs 

The  last  class  contains  the  remainder  of  the  ELLA  language.  It  should  be  noted  that  some 
of  the  features  in  this  list  are  not  available  in  the  commercial  release  ELLA  V4  [Com90a]  but 
they  are  available  in  an  RSRE  version  [HWM90b]  [HWM91]  which  will  form  ELLA  V6,  see 
appendix  B.  Most  of  these  language  features  are  already  transformed  by  software  into  a  series 
of  constructs  in  Core  ELLA  (see  section  2.2).  Thus  although  at  first  sight  this  class  of  language 
features  might  appear  to  encompass  a  large  amount  of  ELLA,  all  language  features  up  to  and 
including  those  of  Release  6  will  be  transformable  into  Core  ELLA. 
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2.S.S.1  Software  Transformations  The  complete  list  of  constructs  for  which  software 
transformations  exist  is 

•  Redundant  brackets  (e.g.  ((bool))  ) 

•  IF  boolean  THEN  unit  ELSE  unit  FI 

•  Named  outputs  (e.g.  FN  A  =  (bool)  — »  (boohout):...) 

•  Multiple  lets  (e.g.  LET  (al,  a2)  =  ...) 

•  Multiple  makes  (e.g.  MAKE  [2][3][2]A:  a.  ) 

•  Complex  joins  (e.g.  JOIN  (true, false)  — *  (al,  a2[2]).) 

•  Replicated  joins  (e.g.  FOR  INT  i  =  1..2  JOIN  ...) 

•  Replicators  (  [INT  i  =  1  ..  n]  ) 

•  INT  declarations  (e.g.  INT  i  =  6) 

•  CONST  declarations  (e.g.  CONST  c  =  (true,  (true  Ifalse)).  ) 

•  Sequences  (e.g.  VAR,  PVAR  etc.) 

•  Macros  (with  INT,  TYPE,  CONST,  FN,  MAC  parameters) 

•  Function  types  (bidirectional  wires  e.g.  fntype  =  bool  — ►  [2]bool) 

•  10  (supplying  the  Input  and  Output  of  a  function  type:  used  in  ‘joining’) 

•  FASTER/SLOWER  (hierarchical  retiming  constructs  e.g.  speed  up/slow  down) 

•  Print /Fault  (macro  expansion  assertions) 

•  Imports/exports  (control  of  functions  through  multiple  contexts) 

•  Renamed  (renaming  of  imported  function) 

•  Static  operators  (e.g.  int/(l+(m*20)  ) 

•  Naming  of  previously  unnamed  input  terminals 

•  Abbreviated  BEGIN. .END  clauses  (e.g.  (...  OUTPUT  ..)) 

•  Series  of  declarations  separated  by  commas  converted  into  separate  declarations 

•  Transport  Delays  converted  into  equivalent  ambiguity  delays 

A  couple  of  constructs  which  cannot  be  transformed  by  means  of  the  software  transformations 
have  been  excluded  from  the  definition  of  Core  ELLA.  These  constructs  can  however  be  sup¬ 
plied  with  ELLA  to  ELLA  syntactic  transformations  which  define  their  behaviour  in  terms  of 
equivalent  constructs  which  can  be  transformed  into  Core  ELLA. 
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2.3.3. 2  Syntactic  Transformations  As  mentioned  in  the  previous  section  there  are  con¬ 
structs  which  have  been  excluded  from  Core  ELLA  for  which  software  transformations  from  the 
complete  language  do  not  exist.  These  constructs  are 

•  CASE  statements  with  ELSEOF  alternatives 

•  Integer  and  character  ranges  in  CASE  choosers 

•  Character  ranges  in  TYPE  declarations 

All  of  these  constructs  can  be  transformed  into  versions  which  are  acceptable  to  the  Core.  For 
example  the  first  item  can  have  the  ELSEOF  parts  removed,  and  the  other  two  items  can  have 
the  ranges  expanded  out.  The  definition  of  syntactic  transformations  for  these  constructs  can 
be  given  in  terms  of  re-write  rules 


language  feature 

semantically  equivalent  language  features 


where  the  ‘language  feature’  above  the  line  is  semantically  equivalent  to  the  set  of  language 
features  below  the  line. 


The  following  syntax  transformation  rules  for  the  above  constructs  are  defined  on  the  full 
language,  the  complete  syntax  for  the  full  language  being  given  in  appendix  B. 


elsof,  =  ELSEOF  cases,  ForAll  i  €  {l..k} 

- 1  CASE  unit  OF  cases  elseofi  •  elseof*  ESA C 

ELLA-Casel  j - — - - - - - 

CASE  unit  OF  cases  elseofi  •  elseof*.i 
ELSE  CASE  unit  OF  cases*  ESAC  ESAC 


elsof,  =  ELSEOF  cases,  ForAll  i  €  {l..k} 

-  CASE  uniti  OF  cases  elseofi  •••  elseofi  ELSE  unitj  ESAC 

ELLA-Case2 - - - 

CASE  uniti  OF  cases  elseof]  •  •  •  elseof*. i  ELSE 
CASE  uniti  OF  cases*  ELSE  unit2  ESAC  ESAC 


ELLA-Rangel 


tagname  /  (  lwb  ..  upb  ) 

tagname  /  lwb  !•••  Itagname  /  lwb  +  (upb-lwb) 


ELLA-Range2 


tagname  (  'firstchar  ..  'last char  ) 


faimamp 


ELLA-Rangc3 


NEW  tagname  (  •  •  •  |  'firstchar  ..  'lastchar  I  •  •  •  ) 

NEW  tagname  (  •  •  •  |  'firstchar  I  •  •  •  I  'lastchar  I  •  •  •  ) 


Having  defined  this  set  of  syntactic  transformations  we  can  now  proceed  to  define  the  syntax 
for  Core  ELLA. 
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2.4  Core  ELLA  Composite  Syntax 

As  defined  in  [BHM90]  a  composite  syntax  combines  the  essences  of  both  the  concrete  and  ab¬ 
stract  syntax  of  a  language.  The  composite  syntax  has  been  defined  to  retain  the  binding  of  the 
concrete  syntax,  thus  it  accurately  represents  the  binding  of  the  ELLA  parser.  The  composite 
syntax  defined  in  this  section  is  summarised  in  appendix  C  . 


In  order  to  define  the  composite  syntax  a  set  of  syntactic  categories  are  need.  Their  definition 
has  been  chosen  in  order  to  maximise  the  readability  of  the  syntax.  Before  proceeding  to  define 
the  categories  some  basic  notation  will  be  given 


2.4.1  Basic  Notation 


Throughout  this  section  the  following  notation  will  be  used 


abc  6  Abe 
b  ::=  c 

I 

I 

d,  •  •  •  d* 

dj,  •  •  • ,  d* 
dii  •  •  •  i  d*.i 


‘abc’  is  an  element  of  the  set  ‘Abc’ 

the  syntax  definition  of  ‘b’  is  ‘c’ 

the  separator  of  alternatives  in  a  syntax  definition 

ELLA  separator  of  alternatives 

one  or  more  occurrences  of  ‘d’ 

one  or  more  occurrences  of  ‘d’  separated  by 

Note  if  k  =  l  then  no  V  is  present. 

zero  or  more  occurrences  of  ‘d’  separated  by  *,’• 

Note  if  k=0  then  no  is  present. 


2.4.2  Syntactic  Categories 

The  categories  used  throughout  this  section  are  described  below.  Words  which  begin  with  an 
upper  case  letter  represent  Sets,  where  ‘Identifier’  is  the  set  of  all  lower  case  names,  ‘Fnname’ 
the  set  of  all  upper  case  names  and  symbols.  Note  that  ‘Identifier’  and  ‘Fnname’  are  disjoint 
Sets.  ‘Character’  is  the  Set  of  all  printable  characters,  whilst  ‘String’  is  the  set  of  all  character 
strings  composed  from  elements  of  ‘Character’.  The  Sets  ‘Z’  and  ‘Nj’  tire  the  Sets  of  integers 
and  natural  non-zero  numbers  respectively. 


typename 

€ 

Identifier 

(ELLA  type  name  e.g.  lower  case) 

signalname 

G 

Identifier 

(ELLA  signal  name) 

tagname 

€ 

Identifier 

(ELLA  tagged  type  name) 

altname 

€ 

Identifier 

(ELLA  enumerated  type  alternative) 

fnname 

6 

Fnname 

(ELLA  function  name  e.g.  upper  case  or  symbol) 

biopname 

G 

Fnname 

(ELLA  BIOP  name  e.g.  upper  case  or  symbol) 

z 

€ 

Z 

(An  integer) 

lwb,  upb 

g 

Z 

(An  integer) 

6 

N, 

(A  non-zero  positive  integer) 

index 

€ 

N, 

(A  non- zero  positive  integer) 

size 

e 

Ni 

(A  non-zero  positive  integer) 

interval 

G 

N» 

(ELLA  timing  interval) 

ambigtime 

€ 

Ni 

(Ambiguity  delay  time) 

delaytime 

G 

Ni 

(delay  time) 

skewtime 

G 

N, 

(skew  delay) 
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con 

initialvalue 

ambigvalue 

char 

string 


6  Constant 
€  Constant 
€  Constant 
6  Character 
6  String 


(‘con’  is  a  value  of  the  ELLA  Constant  type  ‘Constant’) 
(Delay,  Retiming  or  Ram  initialisation  value) 

(Delay  ambiguity  value) 

(A  printable  character  e.g.  ‘a’) 

(A  string  of  printable  characters  e.g.  ‘abc’) 


Some  of  these  names  have  been  taken  from  the  abstract  syntax  (i.e.  delay  parameter  names) 
in  order  to  aid  readability.  We  now  give  the  definition  of  the  Core  syntax. 


2.4.S  Enumerated  Values 

The  following  four  basic  enumerated  values  will  be  grouped  together 

enumerated  ::=  altname 

|  tagname  /  z 
|  tagname  'char 
|  tagname  "string" 

The  symbols  /,  ',  "  are  ELLA  defined  symbol  tags  which  enable  the  ‘tagname’  to  be  correctly 
associated  with  the  appropriate  ELLA  type.  It  can  be  noted  that  the  basic  associated  type 
value  is  missing  from  the  list  since  the  associated  part  is  either  a  constant,  unit  or  type. 


2.4.4  Types 

A  type  in  Core  ELLA  is  defined  to  be 

type  ::  =  typename 

|  STRING  [  size  ]  typename 
t  [  size  ]  type 
I  (  typei,  •••,  type*  ) 

I  0 

where  ‘typename’  is  the  name  of  a  type  declaration  (see  below).  Note  that  the  collateral  of  types 
can  have  just  one  element  which  therefore  allows  redundant  brackets  in  types.  The  constant 
‘size’  is  taken  to  have  a  known  positive  integer  value. 


2.4.5  Constants 

Core  ELLA  constants  have  been  split  into  two  classes  in  order  to  preserve  the  binding  of  the 

concrete  syntax. 

const  ::=  STRING  [  size  ]  constl 

|  [  size  ]  const 
|  constl 

constl  ::=  enumerated 

|  altname  &  constl 
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|  (  const  i,  •  •  •,  const*  ) 

I  •  type 
I  0 

Constants  defined  by  this  syntax  will  be  used  as  initialising  values  in  delays  and  rams. 

2.4.6  Constant  Sets 

Constant  Sets  are  collections  of  constants  which  are  used  as  choosers  in  CASE  statements.  The 
definition  of  Constant  SeU  -Uffers  from  that  of  Constants  in  two  ways.  First  the  inclusion  of  the 
top  level  definition  which  auows  for  constant  alternatives.  Second  the  last  option  of  ‘constset2’ 
is  ‘type’  and  not  ‘?type\  The  last  change  is  necessary  since  it  is  not  possible  to  test  for  ‘?type’ 
in  a  CASE  statement.  The  full  definition  of  Constant  Sets  is 

constset  ::=  constseti  I  •  •  •  Iconstset* 

constsetl  ::=  STRING  [  size  J  constset2 

|  [  size  ]  constsetl 
|  constset2 

constset2  enumerated 

|  altname  &  constset2 
I  (  constseti,  •  •  constset*  ) 

!  type 

2.4.7  Units 

The  syntax  element  ‘unit’  is  the  basic  building  block  for  all  Core  ELLA  descriptions.  Units 
supply  single  or  multiple  values  and  are  composed  of  either  basic  values  or  clauses  which  deliver 
basic  values.  The  definition  given  here  has  three  levels  which  represent  the  levels  of  binding 
given  in  the  concrete  syntax. 

unit  ::=  unit  CONC  unitl 

|  unitl 

unitl  ::=  STRING  [  size  ]  unitl 

|  [  size  ]  unitl 

|  fnname  unitl 

|  altname  Sc  unitl 

|  unit2  //  altname 

|  unit2 

unit2  ::=  signalname 

|  enumerated 

|  unit2  [  index  ] 

|  unit 2  [  index/*,*  ..  index*,*  ] 

|  unit 2  [[  unit  jj 

|  REPLACE  (unit,  unit,  unit) 

I  •  type 

|  closeddause 
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The  last  alternative  of  lunit2’  is  a  dosedclause  which  is  defined  in  the  next  section.  The 
‘signalname’  of  ‘unit2’  is  either  a  MAKE,  LET  or  parameter  name.  The  constants  ‘index’  are 
known  integer  values. 


2.4.8  Closedclause 

Closeddauses  provide  the  mechanism  for  combining  units.  The  CASE  statement  provides  a 
multiplexer- type  construct,  and  the  BEGIN.. .END  clause  gives  a  method  for  signal  naming  and 
introducing  local  declarations. 

closedclause  CASE  unit  OF  cases  ELSE  unit  ESAC 

|  (  unit!,  unit4  ) 

|  BEGIN  step!  •••  step*.!  OUTPUT  unit  END 

I  0 


cases  ::=  constseti  :  uniti,  •••,  constset*  :  unit* 

step  typedec 

|  fndec 

|  LET  signalname  =  unit  . 

|  MAKE  fnname  :  signalname  . 

|  JOIN  unit  — >  signalname  . 


Note  that  within  a  BEGIN  •  •  •  END  clause  there  need  not  be  any  ‘step’s.  The  use  of  step*.! 
implies  that  if  k  =  1  then  no  ‘step’s  are  present.  It  can  be  noted  that  the  ‘signalname’s  are 
handled  differently  in  the  different  ‘step’  declarations.  For  example,  the  ‘signalname’  in  a  LET 
names  the  output  of  the  ‘unit’  and  hence  it  cam  only  be  used  to  supply  a  signal  to  some  other 
part  of  a  circuit.  This  means  that  such  a  signalname  could  not  occur  on  the  right  hand  side  of 
the  arrow  in  a  JOIN  statement.  Whereas  the  signalname  in  the  makedecs  is  naming  a  function 
instantiation  and  hence  has  both  a  value-requiring  part  and  a  value-delivering  part.  This  means 
such  a  signalname  could  be  used  on  either  side  of  the  in  a  JOIN  statement. 


2.4.9  Function  Body 

A  function  body  can  either  be  described  by  a  ‘unit’  or  by  a  function  body  primitive. 

functionbody  ::=  unit 

|  REFORM 
|  BIOP  biopname 

|  DELAY  (  initialvalue,  ambigtime,  ambigvalue,  delaytime  ) 

|  EDELAY  (  initialvalue,  delaytime  ) 

|  SAMPLE  (  interval,  initialvalue,  skewtime  ) 

|  RAM  (  initialvalue  ) 

All  the  basic  syntactic  definitions  of  Core  ELLA  have  now  been  completed.  The  three  remaining 
classes  define  how  the  above  information  is  combined  to  form  a  Core  ELLA  closure. 
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2.4.10  Type  Declarations 
A  Type  declaration  is  of  the  following  form 


typedec 

::=  TYPE  typename  =  typeornew. 

typeornew 

::=  type 

|  new 

new 

::=  NEW  tagname  /  (  lwb  , 

|  NEW  (typealt}  1  ••• 

|  NEW  tagname  (  'chari 

..  upb  ) 

1  typealt*  ) 

!•••  I'char*  ) 

typealt 

::=  altname  &  type 

|  altname 

where  the  alternatives  of  ‘typeornew’  represent:  the  name  of  a  previous  type  declaration,  or  an 
alternative  of  ‘new’  i.e.  an  ELLA  integer,  an  enumerated  type,  or  an  ELLA  character.  The 
enumerated  type  allows  for  some  of  the  alternatives  to  have  associated  values. 


2.4.11  Function  Declarations 
A  function  declaration  is  given  by 

fndec  ::=  FN  fnname  =  input  —  type  :  functionbody. 

input  (  typej  :  signalnamei,  •••,  type*  :  signalname*  ) 

I  0 

2.4.12  Closure 

A  Core  ELLA  Closure  is  the  entry  point  into  a  Core  ELLA  context  and  consists  of  a  number 
of  type  and  function  declarations. 

declaration  ::=  typedec 

|  fndec 

closure  ::=  declaration}  •  •  •  declaration* 


In  any  closure  declarations  are  built  upon  previously  defined  declarations.  Thus  declaration, 
can  only  use  declaration;  where  l<l<i.  Hence  declaration*- is  considered  to  be  the  top  level 
declaration. 
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2.5  Well  Formedness  of  Core  ELLA 

In  this  section  we  consider  the  well  formedness  of  a  description  in  Core  ELLA.  A  well  formed 
description  means  that  the  transformation  rules  from  Core  ELLA  to  the  Kernel  can  be  success¬ 
fully  applied.  The  transformation  rules  described  in  section  3.5  effectively  give  the  conditions 
that  a  Core  description  must  satisfy  in  order  for  the  transformations  to  produce  a  result.  What 
is  missing  from  the  transformation  rules  is  any  indication  of  what  happens  when  conditions 
are  not  fulfilled,  and  this  raises  the  question  of  error  detection.  Throughout  the  development 
of  ELLA  great  emphasis  has  been  placed  on  providing  an  error  detection  and  reporting  sys¬ 
tem  that  gives  the  designer  the  maximum  amount  of  information  possible  in  order  to  facilitate 
correction  of  errors.  This  results  in  a  significant  amount  of  the  compiler’s  time  being  taken 
up  with  the  monitoring  and  handling  of  information  necessary  for  the  error  reporting  system. 
Inevitably  if  a  similar  error  reporting  structure  is  implemented  for  the  transformations  to  the 
Kernel  the  number  of  rules  would  increase  significantly.  Thus,  for  the  present,  we  shall  merely 
consider  the  different  categories  of  errors  that  such  a  transformational  system  would  need  to 
address. 


The  different  categories  of  errors  needed  for  the  transformations  to  the  Kernel  can  best  be 
seen  by  observing  an  abstract  syntax  for  Core  ELLA.  Consider  the  following  data  structure 
(see  [SWH88]  for  a  complete  description  of  an  abstract  syntax  for  the  full  language) 


Closure  Declaration!  ...  Declaration!. 


Declaration  typedeci(ld  x  Typebody) 

|  fndec(Id  x  terminals(Idi  x  Typei  x  ...  x  Idm  x  Typem  )  x 
Type0  x  Fnbody) 


Typebody  ::=  Type 

|  alternative! (Id  x  Type)  ...  alternative! (Id  x  Type) 
|  newchars(Id  x  chars(Chari  x  ...  x  Chari)) 

|  newints(Id  x  Int  x  Int) 

|  tbody-fail 


Type  ::=  tname(Int) 

|  tstr(Typei  x  ...  x  Typet) 
|  trow(Int  x  Type) 

|  t*tring(Int  x  Type) 

|  tnull 
|  tvoid 
|  type-fail 
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Const 


Constset 


Unit 


cbasic(Int  x  Int) 

crow(Int  x  Const) 

cstring(Int  x  Const) 

cassoc(Int  x  Int  x  Const) 

cstr(Consti  x  ...  x  Const*) 

cquery(Type) 

ccharflnt  x  Char) 

cquote(Int  x  Chari  x  ...  x  Char*) 

cvoid 

const-fail 


csalts(Constseti  x  ...  Constset*) 

csbasic(Int  X  Int) 

csrow(Int  x  Constset) 

csstring(Int  x  Constset) 

esassoc(Int  x  Int  x  Constset) 

csstr( Constset i  x  ...  x  Constset*) 

cstype(Type) 

cschar(Int  x  Char) 

csquote(Int  x  Chari  x  ...  x  Char*) 

constset-fail 


cbasic(Int  x  Int) 

cquery(Type) 

cchar(Int  x  Char) 

cquote(Int  x  Char]  x  ...  x  Char*) 

uname(Int) 

uassoc(Int  x  Int  x  Unit) 
uextract(Unit  x  Int  x  Int) 
uindex(Unit  x  Int) 
utrim{Unit  x  Int  x  Int  ) 
udyindex(Unit  x  Unit) 
ureplace(Unit  x  Unit  x  Unit) 
ustr(Unitj  x  ...  x  Unit*) 
urow(int  x  Unit) 
ustring(Int  x  Unit) 
uconc(Unit  x  Unit) 
uminst(instance(Id)  x  Unit) 

ucase(Unit  x  uchoices( Const]  x  Unitj  x  ...  x  Const*  x  Unit*  )) 
u»erie*(series(Stepi  X  ...  x  Step*)  x  Unit) 

uvoid 

unit-fail 
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Step 


Fnbody 


typedec(Id  x  Typebody) 

|  fndec(Id  x  terminals(Idi  x  Typej  x  ...  x  Idm  x  Typem  )  x 
Type,,  x  Fnbody) 

|  let(Id  x  unit) 

|  make(instance(Id)  x  Id) 

|  join(Unit  x  Id) 

I  step-fail 

Unit 

|  reform 

|  adelay(Const  x  Int  x  Const  x  Int) 

|  idelay(Const  x  Int) 

|  ram(  Const) 

|  sample(Int  x  Const  x  Int) 

|  biop(Id) 

|  fnbody-fail 


Where  the  constructors  tbody-fail,  type-fail,  const-fail,  constset-fail,  unit-fail,  step-fail 
and  fnbody-fail  represent  the  different  classes  of  failure.  The  closure  does  not  have  an  explicit 
failure  constructor  since  any  failure  will  occur  in  either  a  typedec  or  a  fndec  and  the  appro¬ 
priate  field  of  those  constructors  would  be  set  to  failure. 


Whilst  it  would  be  relatively  straightforward  to  obtain  a  set  of  transformation  rules  which  were 
the  negation  of  the  rules  in  section  3.5,  the  interaction  of  the  rules  in  the  case  of  errors  would 
require  significant  extra  analysis. 
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3  Kernel  ELLA 

3.1  Introduction 

In  this  section  we  present  the  Kernel  of  ELLA.  The  Kernel  is  a  set  of  data  structures  which 
can  describe  the  complete  language.  The  Kernel  is  not  itself  a  language  since  it  does  not  have 
the  problems  of  scopes  or  type  checking;  these  are  all  taken  care  of  by  the  transformations  from 
Core  ELLA  to  the  Kernel.  Within  the  Kernel  other  simplifications  over  the  Core  have  also 
been  made.  For  example  all  rows  are  converted  to  structures,  and  local  BEGIN..END  clauses 
are  removed  by  means  of  the  use  of  a  transformation  environment.  This  environment  collects 
together  all  the  type  and  function  declarations  and  provides  a  means  of  referencing  declarations 
via  a  global  numbering  system.  As  a  consequence  the  local  type  and  function  declarations 
can  also  be  removed  to  the  outer  level.  Within  each  function  declaration  the  environment  also 
collects  together  all  signal  declarations  and  gives  them  a  unique  reference  number.  Another 
simplification  that  the  environment  allows  is  that  the  MAKE/ JOIN  information  is  added  to 
the  environment  in  a  similar  way  to  an  implicit  function  call  and  hence  this  avoids  the  need  for 
explicit  MAKE/JOINs  appearing  within  the  Kernel. 

Within  the  complete  language  there  is  a  system  of  scope  rules  for  allowing  declarations  to 
use  identical  names  in  separate  parts  of  a  closure.  The  transformational  environment  removes 
all  scopes  by  ensuring  that  each  type  and  function  name  used  in  a  closure,  and  each  signal 
name  used  in  a  function,  has  a  unique  reference  number.  This  number  then  points  into  a 
declaration  field  of  the  environment.  The  rules  governing  this  for  a  BEGIN. .END  clause  work 
in  the  following  way  when  transformation  rule  jCC3]  is  applied  (see  section  3.4.4  for  scoping 
rule  functions,  and  section  3.7.3  for  an  example  of  their  use):  When  a  BEGIN  is  encountered, 
each  local  map  in  the  new  environment  is  set  to  null,  and  each  non-local  map  is  set  to  the 
map  constructed  by  combining  the  local  and  non-local  maps  of  the  previous  environment.  In 
the  case  of  common  arguments,  the  local  entry  overrides  the  non-local  one.  Then  throughout 
the  ensuing  BEGIN. .END  clause  the  local  map  gets  made  up  with  items  that  are  local  to  the 
BEGIN. .END  clause.  At  the  END  the  local  function  names  and  type  names  will  go  out  of  scope 
and  the  declarations  that  were  local  prior  to  entry  to  the  BEGIN. .END  come  back  into  local 
scope.  Thus  on  leaving  the  BEGIN. .END  the  new  environment  takes  the  first  three  fields  from 
the  local  environment  and  all  the  other  fields  from  the  environment  prior  to  the  BEGIN. .END, 
except  for  those  local  names  which  are  now  out  of  scope  and  must  therefore  be  added  to  the 
“used”  fields  to  ensure  that  they  are  not  redefined. 

The  Kernel  has  been  designed  in  its  present  format  so  that  it  should  provide  a  system  for 
mathematical  manipulation  and  that  it  should  interface  simply  with  the  verification  work  of 
the  IED  project  on  “Formal  Verification  Support  for  ELLA”.  Although  all  the  scopes  have 
been  removed,  function  hierarchy  has  not,  even  though  function  declarations  are  now  all  global. 
This  means  that  a  design  can  retain  its  structure.  In  the  next  section  we  describe  the  Kernel 
data  structures,  with  the  transformations  from  Core  ELLA  to  the  Kernel  being  dealt  with  in 
subsequent  sections.  The  complete  Kernel  data  structures  are  summarised  in  appendix  D 


3.2  Conventions 

Throughout  this  section  the  following  conventions  will  be  observed:- 
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abc  € 

Indexer,  Size,  Fnno  C 

Typeno,  Tagno,  Inputno  C 

Signalno,  Ambigtime,  Delaytime  C 
Interval,  Skew  C 

Inputtype,  Outputtype  C 

Initialvalue,  Ambigvalue  C 

Inputfnspec  C 

Fnname,  Biopname  C 

Name,  Signalname  C 

Typename,  Tagname  C 

Lowerbound,  Upperbound  C 

Character  C 

kid  A 

a.b  A 

a[int]  A 


Abc  (ie.  it  is  an  element  of  the  set  Abc) 

Ni 

Ni 

N, 

Nt 

Type 

Const 

"Input  of  function  specification” 

"Upper  case  identifier  or  operator” 
’’Lower  case  identifier” 

’’Lower  case  identifier” 

’’positive  or  negative  integer” 

"printable  character” 

’’object  ”Id”  belongs  in  the  Kernel” 
"Field  selector,  (i.e.  field  ”b”  of  "a”)” 
’’Indexing,  (i.e.  element  ”int”  of  ”a”)” 


with  appendix  A  collecting  together  the  basic  mathematical  notation  used  throughout  this 
section. 

In  the  definition  of  the  Kernel  data  structure,  the  following  naming  conventions  are  also  used: 

o6ci,  abcj,  abc3.  ■  ■  ■  -  abc  separate  instances  of  tuple  abc 

AicSeq  =  Abc  x  •  •  •  x  Abc  non-empty  sequence  of  elements  of  type  Abc 

AbcOpt  -  Abc  i  type  Abc  with  optional  element  nil 

One  of  the  reasons  for  adopting  these  conventions  is  that  names  of  component  types  are  used 
as  field  selectors  for  structured  types.  This  means  that  every  field  needs  to  be  indicated  by  a 
unique  name. 


3.2.1  Links  to  VDM 

It  can  be  noted  that  the  data  structures  definitions  below  naturally  correspond  to  type  defini¬ 
tions  in  the  style  of  VDM.  This  correspondence  is  illustrated  by  means  of  the  following  extract 

of  the  Kernel 

Enumerated  ::=  Enum 

|  string(  Typeno  x  TagnoSeq  ) 

Enum  ::=  enum(  Typeno  x  Tagno  ) 

Closure  ::=  TypedecSeq  x  FndecSeq 

which  corresponds  to  the  following  in  VDM: 

Enumerated  =  Enum  |  String 


Siring  ::  typeno  :  Typeno 
tagnoseq  :  Tagno+ 
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Enum  ::  typeno  :  Typeno 
tagno  :  Tagno 

Closure  =  Typedec +  x  Fndec+ 

The  formal  transformation  rules  and  associated  functions  given  in  subsequent  sections  use  VDM 
notation  [Jon90]  to  define  their  functionality. 


3.3  Kernel  Data  Structure 

In  this  section  we  describe  the  data  structure  model  of  the  Kernel. 

Note  that  all  names  in  the  Kernel  are  referenced  by  integers.  These  are  unique  even  though 
the  scopes  have  been  removed  and  their  identifiers  are  no  longer  unique.  These  integers  index 
the  first  three  fields  of  the  environment  and  the  names  are  merely  attributes  of  the  indexed 
objects.  For  example  ‘Signalno’  in  signal  indexes  the  stgdec  field  of  the  environment  and  the 
original  name  is  obtained  from  the  Signalname  field  of  this  object. 


3.3.1  Enumerated  Values 

Enumerated  values  in  the  Kernel  are  defined  as 

Enumerated  ::=  Enum 

|  string(  Typeno  x  TagnoSeq  ) 

Enum  enum(  Typeno  x  Tagno  ) 

where  Enum  represents  all  the  different  enumerated  types  except  for  STRING  types.  Note  that 
for  integer  ranges  Tagno=l  corresponds  to  the  lower  bound  of  the  integer  range,  even  in  those 
cases  where  the  lower  bound  is  negative. 


3.3.2  Types 

Types  in  the  Kernel  are  defined  by  the  following  structures 

Type  ::=  typeno(  Typeno  ) 

|  typename(  Typename  x  Type  ) 

|  stringtype(  Size  x  Type  ) 

I  types(  TypeSeq  ) 

I  typevoid 

3.3.3  Constants 

Constants  are  the  representation  of  the  constant  class  of  Core  ELLA  which  are  used  for  initial¬ 
isation  of  delays  etc.  and  are  defined  by 
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Const  ::=  Enumerated 

|  conststring(  Size  x  Const  ) 

|  consts(  ConstSeq  ) 

|  constassoc(  Enum  x  Const  ) 
|  constquery(  Type  ) 

I  constvoid 


3.3.4  Constant  Sets 

Constant  sets  are  similar  to  constants  except  that  they  allow  sets  of  alternatives  (i.e.  true  |  false) 

and  are  used  as  choosers  in  case  statements 

Constset  ::=  Enumerated 

|  constsetalts(  ConstsetSeq  ) 

|  constsetstringf  Size  x  Constset  ) 

|  constsets(  ConstsetSeq  ) 

|  constsetassoc(  Enum  x  Constset  ) 

|  constsetany(  Type  ) 

3.3.5  Units 

The  basic  building  blocks  of  a  Kernel  description  are  the  Unit  expressions  which  are  defined 

by 

Unit  Enumerated 

|  conc(  Unit  x  Unit  x  Outputtype  ) 

|  unitstring(  Size  x  Unit  ) 

|  units(  UnitSeq  ) 

|  instance(  Fnno  x  Unit  ) 

|  unitassoc(  Enum  x  Unit  ) 

|  extract  (  Unit  x  Enum  ) 

|  signal(  Signalno  ) 

|  index(  Unit  x  Indexer  x  Outputtype  ) 

|  trim(  Unit  x  Indexer  x  Indexer  x  Outputtype  ) 

|  dyindex(  Unit  x  Unit  x  Outputtype  ) 

|  replace(  Unit  x  Unit  x  Unit  ) 

|  unitquery(  Type  ) 

|  caseclause(  Unit  x  CaseSeq  x  Unit  ) 

|  unit  void 

where  the  different  alternatives  in  Case  clauses  are  given  by 

Case  case(  Constset  x  Unit  ) 

3.3.6  Function  Declarations 

A  function  declaration  has  the  following  data  structure 

Fndec  fndec(  Fnname  x  Inputtype  x  SignaldecSeq  x  Outputtype  x  Fnbody  ) 
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where 

Signaldec  ::=  signaldec(  Signalname  x  Type  x  Unitorinput  ) 

Unitorinput  ::=  Unit 

|  input 

and  the  Function  Body  is  given  by 

Fnbody  ::=  Unit 

|  reform 
|  biop(  Biopname  ) 

|  delay(  Initialvalue  x  Ambigtime  x  Ambigvalue  x  Delaytime  ) 
|  idelay(  Initialvalue  x  Delaytime  ) 

|  sample(  Interval  x  Initialvalue  x  Skew  ) 

|  ram(  Initialvalue  ) 


3.3.7  Type  Declarations 

A  type  declarations  are  of  the  form 

Typedec  ::=  typedec(  Typename  x  New  ) 

where 

New  =  tags(  TagSeq  ) 

|  ellaint(  Tagname  x  Lowerbound  x  Upperbound  ) 
|  chars  (  Tagname  x  CharacterSeq  ) 

Tag  ::=  tag(  Tagname  x  TypeOpt  ) 

3.3.8  Closure 

Finally  a  closure  is  represented  by 

Closure  ::=  TypedecCiq  x  FndecSeq 


3.4  Environments  and  Signatures 

This  section  describes  the  transformational  environment  and  the  signatures  on  Core  ELLA, 
these  are  used  for  defining  the  transformations  from  Core  ELLA  to  the  Kernel. 


3.4.1  Transformation  Environment 

The  environment  (Env)  is  defined  to  be  a  record  object  with  12  fields  which  will  accumulate  type, 
function  and  signal  declarations  and  maintain  information  about  the  scopes  of  identifiers. 


f 
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Env  ::  typedec 

fndec 
sigdec 
fnmap 
Iclfnmap 
tynamemap 
Icltynamemap 
tignamemap 
Iclsignamemap 
u sedtyname 
usedfnname 
usedsigname 


kTypedec * 
kFndec * 
kSignaldec * 

Fnname  Fnno 
Fnname  Fnno 
Name  Typetag 
Name  Typetag 
Signalname  Sig 
Signalname  — *  Sig 
Name-set 
Fnname-set 
Signalname -set 


inv(Env)  & 

(dom  {Env. Icltynamemap)  n  dom  {Env .Iclsignamemap)  n  dom  {Env.signamemap) 
fi  Env. usedsigname  fl  Env .usedtyname  =  {  }) 

A  (dom  {Env. Iclfnmap)  n  Env.  used  fnname  =  {}) 


with  the  following  being  local  to  the  translation  process 


Typetag  =  typeno(  Typeno) 

U  typename(  Typename  x  kType) 
U  consttag(  Typeno) 

Sig  =  sig {Signalno  x  Sort) 

Sort  =  joined  |  unjoined 


(new  TYPE  ) 

(  TYPE  alias  ) 

(  TYPE  tagname  alternative  ) 
(Signal  name) 

(  status  of  signal  input  field  ) 


The  invariant  of  the  environment  is  defined  to  be  inv{Env)  which  states  that  all  signal  and  type 
names  must  be  unique  and  all  function  names  must  be  unique. 

Note  that  the  first  three  fields  of  Env  are  sequences.  The  use  of  each  field  can  be  summarised 
as  follows 

Env. typedec 
Env.  fndec 
Env.  sigdec 
Env.  fnmap 
Env. Iclfnmap 
Env.  tynamemap 
Env .  Icltynamemap 
Env.signamemap 
Env.lclsignamemap 
Env .  usedtyname 
Env.usedfnname 
Env  .usedsigname 

Note  fnname's  are  generated  by  FN  declarations,  tyname's  are  generated  by  TYPE  declarations 
(both  the  TYPE  name  and  their  tags),  and  signame's  are  generated  by  MAKE,  LET  and  input 
parameter  declarations.  The  fields  'used. ..name'  are  the  set  of  all  names  which  have  been  used 
in  the  current  FN  but  are  now  out  of  scope.  This  field  is  used  by  the  'Check'  functions  to 
disallow  their  redefinition.  This  is  a  deliberate  restriction  in  the  full  language  to  ensure  unique 
path  names  in  function  bodies. 


Accumulates  all  typedecs  for  the  final  closure 
Accumulates  all  fndecs  for  the  final  closure 
Accumulates  signaldecs  for  each  fndec 
Fn  name  map  -  visible  outside  the  most  local  scope, 

Fn  name  map  -  in  most  local  BEGIN. .END  scope, 

Type  information  map  -  visible  outside  the  most  local  scope, 
Type  information  map  -  in  most  local  BEGIN.. END  scope, 
Signal  name  map  -  visible  outside  the  most  local  scope, 
Signal  name  map  -  in  the  most  local  BEGIN. .END  scope, 
Type  names  out  of  scope  but  unavailable  for  reuse 
Fn  names  out  of  scope  but  unavailable  for  reuse 
Signal  Names  out  of  scope  but  unavailable  for  reuse 


A 
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The  initial  environment  contains  only  empty  declarations  i.e. 

InitiolEnv  =  env([], 

3.4.2  Built-In  Operator  Environment 

The  environment  for  the  Built-In  Operators  (BiopEnv)  is  a  sequence  of  objects  which  hold  the 
BIOP  name  and  its  typing  information 

BiopEnv  ::  biop  :  kBiop* 

Biop  ::  biopname  :  Fnname 
inputtype  :  kType 
outputtype  :  k  Type 

The  BiopEnv  is  chosen  at  the  outset  and  remains  fixed  for  the  complete  transformation  process. 


3.4.3  Signatures 

Throughout  this  section  a  number  of  signatures  will  be  needed.  The  complete  list  is  given  by 


Scope-Fn-Begin 

Scope-Fn-End 

Scope-Begin 

Scope-End 


Env  — >  Env 
Env  x  Env  — >  Env 
Env  — >  Env 
Env  x  Env  — <  Env 


Check-Joins 
Check-Two- Val 
Check- Fn 
Check-Typename 
Check-Signal 


Env  — >  B 
kType  — *  B 
Fnname  x  Env  — *  B 
Name  x  Env  — »  B 
Signalname  x  Env  — >  B 


Add-Fn 
Add- Type 
Add- Signal 
Add-Join 
Add-Tag 
Add- Type- Name 


Fndec  x  Env  x  Env  — >  Env 
Typedec  x  Env  — *  Env 
Signaldec  x  Sort  x  Env  — >  Env 
Signaldec  x  Signalno  x  Env  — *  Env 
Tagname  x  Env  — >  Env 
Typename  x  kType  x  Env  — •  Env 


Find-Type-Nm 
Find-Sig-Nm 
Find-Fn 
Find-Unjoined 
Find-Type 
Find- Alt 
Find-ELLAint 
Find-Integer-  Type 
Find- Char 
Find- Signal 
Find- Assoc 
Find- Row 
Find-Biop 


Name  x  Env  — »  Typetag 
Name  x  Env  — »  Sig 
Fnname  x  Env  — >  Fnno 
Signalname  x  Env  — >  Fnno 
Typename  x  Env  — >  kType 
Altname  x  Env  - — >  kEnum 

Tagname  x  Env  — *  Typeno  X  Lowerbound  x  Upper  bound 

kType  x  Env  — *  Typeno  x  Lowerbound  x  Upperbound 

Tagname  x  Char  x  Env  — >  kEnum 

Signal  x  Env  — >  kUnit  x  kType 

Altname  x  Env  — •  kType 

kType  — »  Nj  x  kType 

Biopname  x  kType  x  kType  — *  kFnbody 
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Get-Type 

kType  — »  kType 

Type- Equals 

kType  x  kType  — *  B 

Cone 

kType  x  kType  — *  kType 

Is- Char 

Ni  x  Env  — ►  B 

Index 

kType  x  Nj  — >  kType 

Flatten 

kType  — ►  kTypeSeq 

Not-Local-Type 

kType  x  Env  — >  B 

TypeTuple 

kTypeSeq  — ♦  kType 

ConstTuple 

kConstSeq  — ►  kConst 

Constset  Tuple 

kConstsetSeq  — ►  kConstset 

UnitTupIe 

kUnitSeq  — ►  kUnit 

Disjoint 

kConstset  x  kConstset  — *  B 

Env  x  Enum  x  kEnum 

Env  x  Type  x  kType 

Env  x  Const  x  kConst  x  kType 

Env  x  Constset  x  kConstset  x  kType 

Env  x  Unit  x  kUnit  x  kType  x  £ntr 

£nr  x  Closedclause  x  kUnit  x  kType  x  Env 

£nt)  x  Case  x  kConstset  x  kUnit  x  kType  x  kType  x  £nv 

Env  x  Step  x  £nv 

£Yiu  x  A’ete  x  kNew  x  £nv 

Env  x  Typealt  x  Jag  x  Env 

Env  x  Typedec  x  Env 

Env  x  Fndec  x  Env 

Env  x  Builtin  x  A- Type  x  kType  x  kBuiltin 
Env  x  Inputfnspec  x  kType  x  Env 

Env  x  Declaration  x  Env 
Env  x  Closure  x  Env 
Closure  X  kClosure 


kType  x  kType  —  B 

3.4.4  Scopes 

The  scopes  of  Core  ELLA  are  removed  by  the  trims  format  ion  to  the  Kernel.  In  order  to  achieve 
this  the  following  are  needed 
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t- -JclW - 


C 

C 

c 


=S=  - 


Scope- Fn- Begin:  Env  — *  Env 


Scope-Fn-Begin{  E )  A 
env(  E.  typedec, 

E.fnmap  t  E.lclfnmap, 

U, 

{} 


E. fndec,  [  ], 

{  },  E.tynamemap  f  E.lcltynamemap, 

{},  o 

{}  {}) 


Jh 
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Scope-Fn-End:  Env  x  Env  — »  Env 

Scope-Fn-End(E,  L)  A 

env{  L.typedec,  L.fndec , 

E.fnmap,  E.lclfnmap  f  L.lclfnmap , 

E.tynamemap ,  E.lcltynamemap  f  L.lcltynamemap, 
E.signamemap,  E .Iclsignamemap , 

E.usedtyname,  E.usedfnname 


E.sigdec, 


E  .usedsigname) 


Scope-Begin:  Env  — *  £Vit> 

Scope-Begin(E)  A 

env(  E.typedec,  E.fndec,  E.sigdec , 

E.fnmap  f  E.lclfnmap ,  {  }, 

E.tynamemap  f  E.lcltynamemap ,  {  }, 

E.signamemap  t  E. Iclsignamemap,  {  } 

E.usedtyname  E.usedfnname  E. usedsigname) 


Scope-End:  Env  x  £nr  — »  fnr 


Scope-End(E,  L)  A 

env(  L.typedec , 

E.fnmap , 

E.tynamemap , 

E.signamemap , 

E.usedtyname  t  dom  (I. Icltynamemap) 

E. usedsigname  f  dom  (I. Iclsignamemap)) 


L.fndec , 

E.lclfnmap, 

E.lcltynamemap, 

E. Iclsignamemap, 

E.usedfnname  f  dom  (L.lclfnmap) 


L.sigdec, 


The  stacking  and  unstacking  of  the  scopes  for  BEGIN. .END  clauses  is  carried  out  through  the 
transformation  rule  [CC3].  Whilst  the  stacking  and  unstacking  of  local  function  and  type  dec¬ 
larations  are  carried  out  through  the  transformation  rules  [SPlj  and  [SP2]. 


S.4.S  Join  Checks 

The  Check-Joins  predicate  is  used  to  ensure  that  all  local  signals  in  an  Environment  have  been 
joined. 

Check-Joins  :  Env  — *  B 

Check- Joins(E)  A  Vj  g  rng  E. Iclsignamemap  ■  s. sort  =  joined 


3.4.8  Two  Value  Types 

Here  we  present  the  predicate  for  checking  that  a  type  is  a  two  valued  enumerated  type: 
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Check- Two- Val  :kType  — *  B 

Check-Two- Val(ty)  A 

let  typeno(  typeno)  =  ty  in 
let  (E.typedec)[typeno\.new  =  tags (TagSeq)  in 
len  (  tags(  TagSeq))  -  2 


3.4.7  Check  names 

These  predicates  ensure  that  a  particular  name  is  not  already  in  scope.  They  will  be  used  by 
the  functions  that  add  names  to  an  Environment. 

Check-Fn :  Fnname  x  Env  — *  B 

Check- Fn(fnname,  E)  A 

fnname  &  (dom  (E.lclfnmap)  u  E.usedfnname) 


Check- Typename:  Name  x  Env  —>  B 

Check- Typename (name,  E)  A 

name  £  (dom(E.lcltynamemap)  U  E.usedtyname) 


Check-Signal:  Signalname  X  Env  —  B 
Check- Signal  (signalname,  E)  A 

signalname  $  (dom  (E .signamemap)  U  dom  (E .Iclsignamemap)  U  E.usedsigname) 


3.4.8  Adding  Names  to  an  Environment 

These  functions  define  the  addition  of  names  to  an  environment 
Add-Fn:  Fndec  x  Env  x  Env  — *  Env 
Add-Fn(fd,EuE3)  A 

let  E  —  n(Ei,  {typedec  •-*  E3.typedec,  fndec  *-*  Ej.fndec})  in 
let  Len  =  len  E. fndec  in 
let  FnName  =  fd.fnname  in 
fs(E,  {  fndec  ~  E. fndec  *  \fd], 

Iclfnmap  <—  ( E.lclfnmap  t  {FnName  >—  Len  +  1}) 

} 

) 

pre 

Check- Fn(fd. fnname,  E i) 


ELLA  Static  Semantics 


33 


Add-Type:  Typedec  x  Env  — *  Env 

Add-Type(td,  E)  A 

let  Len  —  len  E. typedec  in 
let  TyName  =  td.typename  in 
H(E,  {  typedec  ►-+  E. typedec  n  [td], 

Icltynamemap  i-»  ( E.lcltynamemap  f  {  TyName  »-*  typeno(Ien  +  1)}) 

} 

) 

pre 

Check- Typename{td. typename,  E)  A  Check- Signaled,  typename,  E) 


Add-Signal:  Signaldec  x  Sort  x  Env  — *  Env 

Add-Signal{sd,sort,  E)  A 
let  Len  =  len  E.sigdec  in 
let  SigName  =  sd.signalname  in 
/i(£,  {  sigdec  •->  E.sigdec  n  [id], 

Iclsignamemap  •— *  (E  .Iclsignamemap  f  {SigName  — 
sig (Len  +  1,  iorf)}) 

} 

) 

pre 

Check- Signaled . signalname ,  E )  A  Check-  Typename(sd .signalname ,  E) 


Add-Join:  Signaldec  x  Signalno  x  — »  Env 

Add-Join(sd,  signalno,  E)  A 

let  SigName  =  sd.signalname  in 
{  sigdec[signalno]  •-»  id, 

Iclsignamemap  (E. Iclsignamemap  ]  {SigName  >-> 

sig(i^na/no,  joined)}) 

} 

) 


Add-Tag:  Tagname  x  £nt>  — *  Env 

Add-Tag(tagname,  E)  A 

let  ien  =  len  E .typedec  in 

p(JE\  Icltynamemap  *-*  ( E.lcltynamemap  t  {ta^nome  «-*  consttag(Len  +  1)})) 
pre  ' 

Check-  Typename(tagname,  E)  A  Check- Signal ( tagname,  E) 


Add-Type-Name:  Typename  x  kType  x  ffav  — *  J?nt> 

Add- Type- N ame {typename,  ktype,  E)  A 

p(£,  Icltynamemap  •-*  {E.lcltynamemap  f  {typename  typen ame( typename,  fctype)})) 

pre 

Check- Typename(typename,  E)  A  Check-Signal{typename,  E) 
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3.4.9  Finding  Names  in  an  Environment 

These  functions  describe  how  any  name  can  be  located  within  tin  Environment 

Find- Type- Nm:  Name  x  Env  — *  Typetag 

Find-Type-Nm(name,  E)  A 

( E.tynamemap  f  E.lcltynamemap)(name) 


Find-Sig-Nm:  Name  x  Env  — *  Sig 

Find-Sig-Nm($ignalname,  E)  A 

( E.signamemap  f  E  .lclsignamemap)(signalname) 


Find-Fn:  Fnname  x  Env  —>  Fnno 

Find-Fn(name,  E)  A 

( E.fnmap  f  E .lclfnmap)(name) 


Find-  Unjoined:  Signalname  x  Env  — *  Fnno 

Find-  Unjoined(signaIname ,  E)  A 

let  Signo  -  (E  .lclsignamemap)(signalname).signalno  in 

let  signaldec (signalname,  type,  instance(/nno, .))  =  (E .sigdec)[Signo]  in 

fnno 

pre 

(E.lclsignamemap)(signalnit<ne).sort  —  unjoined 


Find- Type:  Typename  x  Env  — *  kType 

Find-Type(typename,  E)  A 

Find-Type-Nm(typename,  E) 

pre 

Find-Type-Nm(typename,  E)  €  (  typename  U  typeno) 


Find- Alt:  Altname  x  Env  — *  kEnum 
Find-Alt{altname ,  E)  A 

let  conuttng(ktypeno)  =  Find- Type- Nm(altname,  E)  in 
let  typedec(.,  tags ( tags))  =  (E.typedec)[ktypeno]  in 
let  index  =  i  (i  €  ind*  tags )  •  ta$s[t]  =  tag  (altname, .)  in 
enu m(ktypeno,  index) 
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Find-ELLAint:  Tagname  x  Env  — *  Typeno  x  Lowerbound  x  Upperbound 

Find-ELLAint  (tagname ,  £)  A 

let  eonsttag(ktypeno)  =  Find-Type-Nm(tagname,  E)  in 
let  typedec(_,  ellaint(_,  /i,  ub))  =  (E  .typedec)[ktypeno]  in 
ktypeno,  lb,  ub 


Find-Integer- Type:  kType  X  Env  — *  Typeno  x  Lowerbound  x  Upperbound 

Find-Integer-  Type(ktype,  E)  A 
cases  ktype  of 

typeno( typeno)  — ►  cases  (£'.tyj>edec)[tj/peno]  of 

typedec(_,  ellaint(t,  i,  u))  — *  t,  /,  u 

end 

typename(.,  type) —>  Find-Integer- Type(type) 

end 


Find-Char:  Tagname  x  C7iar  x  Em;  — *  kEnum 

Find- Char  (tagname,  char,  E)  A 

let  consttag(ktypeno)  =  Find-Type-Nm(tagname,  E)  in 
let  typedec(-,  chars(_,  c/is))  =  (£'.fj/pedec)[fctt/peno]  in 
let  index  =  i(i  £  indsc/is)  ■  cAs[t]  =  c/iar  in 
en\im(ktypeno,  index) 


Find-Signal:  Signal  x  £ni>  — <  kUnit  x  kType 

Find-Signal(signalname,  E)  A 

let  %ig(signalno, .)  =  Find-Sig-Nm(signalname,  E)  in 
signal( signalno ) ,  ( E.sigdec){ signalno]. type 


Find-Assoc:  Altname  X  Env  — >  kType 
Find-A»oc(altname,  E)  A 

let  con«ttag(  fctypeno)  =  Find-Type-Nm(altname,  E)  in 
let  typedec(.,  tagi( tags))  =  (E  .typedec)[ktypeno]  in 

i(ktypeOpt  £  kTypeOpt)  ■  tag(  altname,  ktype  Opt)  £  elems  tags 
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Find-Row.  kType  -*  x  kType 

Find- Row  ( ktype )  A 

let  types  (types)  =  ktype  in 
let  size  =  len  (types)  in 

(size,  tyj>es[l]) 

pre 

types[l]  =Tt~|=  types[t]  ForAll  i  £  {l..size} 


Find-Biop:  Biopname  x  kType  x  kType  — ►  kFnbody 

Find- Biop(name,  ktype i,  ktype 2)  A 

let  biopinfo  =  i(i  £  BiopEnv.biop)  •  i. biopname  =  name  in 

biop  (name) 
pre 

(biopinfo. inputtype  =J T  [=  ktype \)  A  (biopinfo. outputtype  =)  T }=  ktype 2) 


3.4.10  Removing  Type  Aliasing 

Type  aliasing  is  removed  by  means  of  the  following  function: 


Get- Type  :  kType  —  kType 

Get-Type(ty)  A 
cases  ty  of 

types  ([ktype  1 ,  ■  ktype k})  —  types((GeMVpe(/:<j/pei ),  •  •  • ,  Get-Type(ktypek)}), 

typenamef. ,  ktype)  — *  Get- Type  (ktype) 

stringtype(size  ,  ktype)  — >  stringtype(size,  Get-  Type(ktype)) 

others  ty 

end 


3.4.11  Type  Checking 

Type  checking  is  an  important  aspect  of  the  ELLA  compiler  and  the  relation  ‘a  =j  T  j—  b'  shows 
how  the  transformation  from  Core  ELLA  to  the  Kernel  will  define  type  equality.  This  relation 
is  defined  by:- 


ktypei  =©=  ktype 2  o  Type-Equals(ktype1,  ktype3) 


where 
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Type- Equals  :  kType  x  k Type  — »  B 

Type-Equals(  tyx,ty2)  ^ 

cases  (Get-Type(tyx),  Get-Type(ty2))  of 

(  typeno( typenox),  typeno( typeno2))  -*  (typenox  =  typeno2) 

(  stringtype(s!,  tnx),  stringtype(s2,  tn2)) ->  (sx  =  s2)  A  Type-Equals(tnx,tn2) 
(  types([ti,...,tt]),  types([«1). ..,«,]))  ->  j  =  k  /\  Type-Equals(t„  st) 

(  typevoid,  typevoid)  — *  true 

others  false 

end 


3.4.12  Concatenation 

Concatenation  of  two  signal  types  are  handled  by  means  of  the  following  function. 


Cone  :  kType  x  kType  — >  kType 
Conc(tyi,ty2)  & 

cases  (Get-Type(tyx),  Get- Type(iy2))  of 

(  types([taj,  •  •  • ,  to;]), 

types([<61,...,t6/j))  let  (Vie  {l..*}j€  =ff]=  =  true  *" 

types((taj,.--,tat,f6i,---,t6/]) 

(  types([l, ,•••,<*]),  .)  —  let  (Vie  {l..k}  •  t,  ={t]=:  ty2)  =  true  in 

types ([«),•••,  4,  <y2]) 

(.,  types((tj,  •  •  • ,  fi]))  —  let  (Vie  {l-fc}  •  t,  4^1=  tyx)  =  true  in 

types([fyi,  <!,•••,  ft]) 

(  stringtype(size0,  ktypea), 

stringtype(srVe4,  ktype  k))  — *  let  (ktype„  ={~T~]=  ktypek)  =  true  in 

stringtype( size,  size k,  ktype a) 

(  stringtype  (size,  ktype),  .)  -♦  let  (fctype  ={t]=  ty2)  =  true  in 

stringtype( size  +  l,  ktype) 

(.,  stringtype( size,  ktype))  — »  let  (tyx  ={t]=  ktype)  =  true  in 

stringtype(size  +  1,  ktype) 

end 


3.4.13  Character  Check 

This  rule  checks  that  a  particular  type  is  of  the  form  of  an  ELLA  character. 
Is-Char  :Ni  x  Env  — *  B 

Is-Char(typeno,  E)  ^  (E.typedec)[typeno].new  G  chars 
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3.4.14  Type  Indexing 

This  function  describes  how  to  obtain  the  type  of  an  indexed  type 

Index  :  kType  x  Ni  — ►  kType 

Indez(ty,i)  ^ 

cases  Get-Type(ty)  of 
types ([*type1(  •  •  • ,  ktypek])  -*  ktypei, 
stringtype( . ,  ktype)  — >  ktype 

end 


3.4.15  Reform 

This  function  flattens  types  so  that  they  are  available  for  reform 


Flatten  :  k  Type  — *  kTypeSeq 

Flatten(ty)  ^ 

cases  Get-Type(ty)  of 

typeno  (typeno)  -*  [  typeno( typeno)), 

stringtype  (size,  ktype) —>  [  stringtype( size,  ktype)}, 
types  ([*!,•-•,  tfc])  — »  Flatten(ti)1^  ■•■r*  Flatten(tk) 

typevoid  — >  [  typevoid] 

end 


3.4.16  Local  Type  Checking 

This  function  checks  that  its  input  type  is  not  a  locally  declared  type,  and  will  be  used  by  local 
BEGIN..END  clauses  to  ensure  that  the  output  from  the  clause  only  contains  global  types. 

Not- Local- Type  :  k  Type  x  Env  — *  B 

Not- Local- Type(ktype,  E)  A 
cases  Gei-Type(ktype)  of 

typeno  (typeno)  — *  V(»€  mg  E  .Icltynamemap)  ■  i  ^  typeno  (typeno) 

type»([h, •••,<»])  -*■  A  Noi-Iocal-Type(U,  E) 
i€  {!••»} 

•tringtype( size,  t)  -*  Not- Local-  Type(t,  E) 
others  true 


end 
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3.4.17  Constructing  Tuples 


These  functions  convert  sequences  into  tuples. 


Type  Tuple  :  kTypeSeq  — *  kType 

TypeTuple(tseq)  &  iflentseg  =  l 
then  fseg[l] 
else  types  ( tseq ) 


ConstTuple  :kConstSeq  — ►  kConsl 

ConstTuple(cseq)  A  if  len  cseq  =  1 
then  cseg[l] 
else  consts  (cseq) 


ConstsetTuple  :  kConstsetSeq  — *  kConstset 

ConstsetTuple(csseq)  ^  if  len  csseq  =  1 

then  csseq[l] 

else  constsets  (csseq) 


UnitTuple  -.kUnitSeq  — *  kUnit 

UnitTuple(useq)  &  iflenuseg=l 
then  useg[l] 
else  units  (useq) 


3.4.18  Case  Disjointness 

Within  CASE  statements  all  the  different  arms  must  have  distinctive  choosers.  In  order  to 
ensure  this  the  following  is  needed. 


40 


Kernel  ELLA 


Disjoint :  kConstset  x  kConstset  — »  B 

Disjoint(cset2,  cset2)  ^ 
csttt  (cseti,  csetj)  of 
(  enum(.,<affnoi),  enum(.,l4jno2)) 

(  *tring(.,  [*a5noii> •  •  • ,  taynon]), 
string (.,  [tagnoju  •  -  * ,  ta^Tio2i])) 

(  constsetassoc(  enum(-,  tagnoi),  constseti), 
constsetassoc(  enum(.,  tagno2),  constseti)) 

(  constsets([csai,  •  •• ,  csa*]), 
constsets([cs6i,  •  •  •,  cs&t])) 


(enum,  constsetalts([csoi,  •  •  • ,  csa*])) 

( constsetalis ,  enum) 

(  constsetalts([csaa,  ■  •  csa*]), 

constsetalts) 

(  constsetstring(suea,  csefa), 
constsetstring(siiek,  csei*)) 

(  constsetany(fype),  .) 

(-,  constsetany(fj/pe)) 

end 


tagnoi^-  tagno2 

V  ( tagnou ^  tagno2l) 

•={ i-*} 

tagnoi^  tagno2  V 
Disjoint(constset\ ,  constseti) 

\J  Disjoint(csa,,  csb,) 

Disjoint(enum,  csa,) 

•={!■•* } 

Disjoint(enum ,  constsetalts) 

^  Disjoint(csa,,  constsetalts) 
i={i..k) 

(size sizeb)  V 
Disjoint(cseta,  cse4) 
false 
false 


3.5  Formal  Transformation  System 

This  section  describes  transformations  from  Core  ELLA  to  the  Kernel.  These  include  the 
semantic  checks  which  are  done  by  the  full  ELLA  compiler  on  Core  ELLA  ie.  type  checking, 
name  checking  etc.  Thus  this  section  includes  a  description  of  the  static  semantics  of  Core 
ELLA.  At  the  start  of  each  subsection  the  Core  ELLA  syntax,  for  which  the  transformations 
of  that  section  apply,  will  be  given. 


3.5.1  Enumerated  Values 

Enumerated  values  are  defined  by 

enumerated  ::=  alt  name 

|  tagname  /  z 
|  tagname  'char 
|  tagname  "string" 

and  the  transformations  on  them  are  given  by 


EMI 


Find-Alt  ( altname,E )  =  enum (ktypeno,  index) 


E  H  [a/tname]  =j  EM  (= 


enum  (ktypeno,  index) 
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EM2 


Find-ELLAint  (tagname,  E)  =  ktypeno ,  lb,  ub 


E  H  [tagname/z]  =j  EM  =>  enum(ktypeno,  z-lb 


lb<  z<  ub 

+  1) 


EM3 


Find-Char  ( tagname ,  char,E)  = 


E  I-  [tagname  ' char J  ^  EM 


enu m( ktypeno,  index) 
enum(J ktypeno,  index) 


EM4 


Find- Char  (tagname,  chari,  E)  =  enum(ktypeno,  ktagno,)  For  All  t'G  { 1 } 


E  h  [ tagname  "chari  •  •  •  char*"]  =|  EM  string(  fctypeno,  [feia^noi,  ■  •  • ,  fctayno*]) 


3.5.2  Types 

Types  in  Core  ELLA  can  have  the  following  form 

type  ::=  typename 

|  STRING  [  size  ]  typename 
|  [  size  ]  type 
I  (  typei,  •••,  type*  ) 

I  0 

and  the  transformations  that  apply  to  them  are 


Tl 


Find- Type  (typename,  E)  =  ktype 
E  t-  [typename]  ={t}=>  ktype 


E  H  {typename]  =  ~T~j=>  ktype  Get-Type(ktype)  =  typeno (ktypeno)  Is-Char  ( ktypeno ) 
E  t-  [ STRING[size]typename ]  =|~T~j=>  stringtype(s:ze,  ktype) 

_ E  h  [type]  =Tt]=>  ktype _ 

E  h  [[size] type]  =TtT=>  types ([^type""]) 

■^1  E  I-  (type,]  4tW  t,  ForAll  i€  {!..&} 

Eh  [(typei,---,type*)]  TypeTuple([ti,---,tk)) 


T5 


£!-[()]  =fTk  typevoid 


42 


Kernel  ELLA 


S.5.S  Constants 

The  Core  ELLA  definition  of  constants  is 

const  ::=  STRING  [  size  ]  constl 

|  [  size  ]  const 
|  constl 

constl  ::=  enumerated 

|  ait  name  &  constl 
|  (  consti,  •  •  •,  const*  ) 

I  ?  type 

I  0 


with  their  transformation  rules  being 


Cl 


E  I-  [constl]  =j  C  |=>  kconst:  typeno (ktypeno) 

Js-Char  ( ktypeno ,  E) 

E  (-  [ST/t/NG [me] constl]  =fcl=> 
conststring]  me,  kconst):  stringtype(me,  typeno  (ktypeno)) 


C2 


E  H  [const]  =j  C  p  kconst:  ktype 


E  [[sizejconst]  =fc~W  consts([kconst'u<]):  types]  [ktype*"']) 


C3 


E  I-  [enumerated]  -  EM  \=>  enum (ktypeno,  tagno) 


E  H  [ enumerated ]  =~C~^>  enum(  ktypeno,  tagno):  typeno  (ktypeno) 


C4 


E  I-  [enumerated]  =|  EM  R  string  (ktypeno,  tagnoseg) 


EH  [enumerated]  =[  C  R  string]  ktypeno,  tagnoseq):  typeno(ktypeno) 


C5 


E  h  [constl]  ={C>  kconst:  ktype\ 

Find- Assoc  (altname,  E)  =  ktype j 

ktype i  =[t]=  ktype j  Find- Alt  (altname,  E)  =  enum] ktypeno,  index) 


E  H  [altname k constl]  =j  C  ]=> 

constassoc]  enum] ktypeno,  index),  kconst):  typeno] ktypeno) 


E  I-  [const*]  =fc~|=»  kconst,:  ktype i  ForAll  t‘6  {1..&} 

E  H  [(consti,  •  •  • ,  const*)]  =fc]=>- 
Const7bp/e([kcons«i,  •  •  kconst*]):  Type  Tuple  ([ktype  i,  ■  •  ktype*]) 
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C7 


E  (-  [type]  ktype 

E  t-  [?type]  =fcW  constquery(fctype):  ktype 


C8j - — - 

E  I-  [()]  H  C  constvoid:  typevoid 


3.5.4  Constant  Sets 
Constant  sets  are  given  by 


const  set 

constseti  I  •  •  •  I  constseti 

constsetl 

Zlzz 

STRING  [  size  ]  constset2 
|  [  size  ]  constsetl 
|  constset2 

constset2 

■ 

enumerated 
|  altname  &  constset2 
!  (  constseti,  •  •  •,  constseti  ) 

1  type 

with  transformations  on  them  given  by 


CS1 


E  H  [constsef,]  ={_CSj=>  kcset,:  ktype,  ktype,  =j  T  |=  ktypei  ForAll  {l..fc} 


E  t-  [constseti  |  •  •  •  |  constseti]  CS  {=>  constsetalts([fccseti,  •  •  •,  kcsett]):  ktype i 


E  t-  [con»ts«f2j  =j  CS  kcset:  typeno (ktypeno) 

Is-Char  ( ktypeno ,  E ) 

E  t-  [5T.R/ArG[me]conjt*et2]  =j  CS  [=> 

conitietitring(<i2e,  kcset).  stringtype(*ue,  typenof ktypeno)) 


CS3 


E  H  [constsetl]  =|CS  =»  kcset:  ktype 


E  h  [[size]  constsetl] 


constsets([fccsef'’“]):  types([fctype*“']) 


CS4 


E  t-  [enumerated]  =)  EM  =»  enu m(ktypeno,  iagno) 


E  H  [enumerated]  CS  }=>  enu m(ktypeno,tagno):  typeno( ktypeno) 


CSS 


E  t-  [enumerated]  =[EM_  =>  string  (ktypeno,  tagnoseq) 


E  H  [enumerated] 


» t ring (fc typeno,  tagnoseq):  typeno(  ktypeno) 


44 


Kernel  ELLA 


CS6 


E  t-  [contt$ei2]  H  CS  |=>  kc»et:ktype\  Fxnd-Attoc  (altname,  E)  =  ktype2 
ktype \  =fxl=  ktype  j _ Find-Alt  (altname,  E)  =  «an m(ktypeno,  iagno) 


E  h  [aftnamefccofui«et2]  =|_CSj=> 
constsetassoc(  enum (ktypeno,  iagno)  ,kaet):  typeno (ktypeno) 


CS7 


E  h  [ constset ,]  ^  CS  =»  besets  ktypei  Forall  t'G  {l..fc} 


Eh  \(con$Ueli,- ■  ■  yContUeti)]  ^  CS  |=» 
Conit$etTvplc([kc*eti,  •  -  ieset*]):  Type  Tuple  ([ktypei,  •  •  • ,  itype*]) 


CS8 


E  h  [  type J  =[T>  ktype 


E  h  [type]  ={  CS  =>  constsetany (ktype):  ktype 


3.5.5  Units 


The  complete  Core  ELLA  unit  syntax  is  given  by 

unit  ::=  unit  CONC  unitl 

|  unitl 

unitl 

::=  STRING  [  size  ]  unitl 

|  (  size  ]  unitl 
|  fnname  unitl 
|  altname  &  unitl 
|  unit2  / /  altname 
|  unit2 

unit2 

::=  signalname 

|  enumerated 
|  unit2  [  index  ] 

|  unit2  [  indexes  ..  index.,*  ] 

|  unit2  [[  unit  ]] 

|  REPLACE  (unit,  unit,  unit) 

1  ’  type 

1  doseddause 

with  the  transformations  defined  by 


— — |  Find-Signal  (signalname,  E)  =  signal(  sign  a/no),  ktype 
E  h  [siyna/namej  =Tu~|=>  signal (signalno):  ktype,  E 

E  h  f  enumerated]  =|  EM  enum(  ktypeno,  iagno ) _ 

E  t-  [enumerated!  =fu]=>  enum( ktypeno,  tagno):  typen o(ktypeno),  E 
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j _ E  h  [enumerated]  =j  EM  (=>  »tring( ktypeno,  tagnoseq) 

E  t-  f enumerated ]  =Tu~|=>  ■trmg(fctypeno,  tagnoseq):  typeno(fctypeno),  E 

E  t-  [unit]  U  }=>  kunit j:  ktype  \ ,  £1 
.El  h  [until]  =j  U  f=>  kunit  2:  ktype 2,  E2 

_ ktype aut  =  Conc(ktype2,  ktype2) _ _ 

.£  H  [unit  CONC  until]  =fu]=>  conc(fcuniti,  kunit  2,  ktype  ovt ):  ktypeout,  E2 

E  h  [unitl]  =fuW  *unit:  typeno (ktypeno),  E' 
r- — I  Is-Char  ( ktypeno ,  E) 


E  h  [STRING[»ize)unitl]  =fu]=> 
unit string( size,  kunit):  »tringtype( size,  typen o(ktypeno)),  E‘ 


— — _ E  (-  [unitl]  =  U  =>  kunit:  ktype,  E' 

E  h  {[sue]  unitl]  =fu~W  units([fcunif**“]):  types([fcty/>e''2']),  E' 

E  h  [unitl]  ={u>  kunit:  ktype ,  E' 

/nno  =  Find-Fn  (fnname,  E) 

(E ,fndec)[fnno].inputtype  =)  T  ]=  ktype 

Eh  [fnname  unitl]  =fu]=»  instance(fnno,  kunit):  ((E.fndec)[fnno].outputtype),  E' 

E  h  [unttl]  U  (=>  kunity.  ktype  j,  E' 

Find- Assoc  (oltname,  E)  =  ktype2 

I - 1  ktype  1  T  |=  ktype 2 _ Find-Alt  (altname,  E)  =  enum(ktypeno,  tagno) 


E  I-  [a/tname&umtl]  =j  U 

unitaifoc(  enutn (ktypeno ,  tagno) ,  kumt\):  typeno(ktypeno),  E' 


E  h  [umt2]  =j  U  kunit:  ktype,  E'  Find-Assoc  (altname,  E)  =  ktype, 
Find- Alt  (altname,  E)  =  enum( typeno,  index), 
typenof  typeno)  T  |=  ktype 

E  h  \unit2  /  /  altname\  extract (fcunit,  enum( typeno,  index)):  ktype ,  E' 

Eh  [unit  2]  =j  U  kunit:  ktype,  E'  Index  (ktype,  index)  =  t 

-  Find- Integer- Type (t,  £’)  =  ktypeno,  l,  u  l<  *ndex<  u 

U10 - 1 - — - 

E  I-  [untl2f  index  H  =Jul=>  index(fcunit,  index,  t):  t,  E' 


E  h  [untt2]  =j  U  |=>  kunit:  ktype,  E' 

Index  (ktype,  index  tvi)  =  (  Index  (ktype ,  index  =  t 

Find- Integer- Type (t,  E')  =  ktypeno,  l,  u  l<  index ivi<  indexes  u 


E  H  \unit2[indezivi..indezurs\\  =^ul=>  trim(kunii,  indexes,  index Ufyt):  t,  E' 
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U12 


E  I-  [unit 2]  =^_U_j=>  tuntti :  ktype i ,  E\ 

E\  h  [unit]  =)  U  ^  iunitj:  ktypej,  E' 
Find-Integer-Type(ktype2,  E')  =  ktypeno,  l,  u 
Fxnd- Row  (ktype  \)  =  size,  tt  1  <  /<  u<  size 


E  [unif2[[unit]]]  =^"u~)=»  dyindex(fcuniti,  Jkunitj,  ft):  tt,  E' 


U13 


E  H  [uniti]  =j  U  ).»  Jtunitj:  ktype\ ,  E\ 

E\  I-  [unit]]  =j  U  L>  kunitj:  ktypej, 

Ei  I-  [unit]]  4uh>  tunif]:  ktype3,  E' 
Find- Integer- Type  (ktype  3,  E3)  =  ktypeno ,  l,  u 
Find- Row  (ktype  3)  =  tize,  t 
1<  /<  u<  lize  ktype ^  T  |=  t 


E  K  [REPLACE(unit\, 


unit],  unit])]  =^U 


replace ( fcunif j, fcunit 2,  kunit3):  ktype lt 


E' 


U14 


E  t-  [type]  =J~T~  =>  ktype 

E  I-  [?fype]  =|~U~W  unitquery(fctype):  ktype,  E 


U15 


E  I-  [c/oseddause]  =  CC  b*  kunit:  ktype,  E' 


E  I-  [closedclause]  ={u]=>  kunit:  ktype,  E' 


3.5.6  Closedclause 


Closed  clauses 

are  given  by 

closedclause 

::=  CASE  unit  OF  cases  ELSE  unit  ESAC 

|  (  uniti,  •  •  •,  unit*  ) 

|  BEGIN  stepi  ■  •  •  step*.!  OUTPUT  unit  END 

1  0 

cases 

::=  constseti  :  uniti,  •••*  constset*  :  unit* 

step 

::=  typedec 

|  fndec 

|  LET  signalname  =  unit  . 

|  MAKE  fnname  :  signalname  . 

|  JOIN  unit  — >  signalname  . 

with  the  transformations  given  by 


CA 


E  t-  [conflict]  =[CS>  kconsieet:  ktypecontt 
E  t-  [unit]  =  _U_^  tunif:  ktype,  E' 


E  (-  [constsef:  unit]  b  CA  kconstset,  kunit:  ktypeconst,  ktype,  E' 
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CC1 


_ E  P  [unit!]  4UW  kvnitin:  ktypein ,  Ex 

Ei  P  [case,]  =)  CA  |=>  tc*j,  tu;:  ktypecit  ktypeui,  E<  +  i  ForAll  i£  {l..i} 

+  1 1-  [imtlj]  =[ul=>  kunit  out‘  ktype  out,  E' 

ktypeci  =fT~t=  ktyptin  ktypeui  ={t}=  ktype out  ForAll  ie  {1  -  k} 

Dujoint(kc»i,  kctj)  ForAll  i,j£  {1..4}  j 


E  P  [CAS.E  until  OF  casek,  •  • 
caieclause(jtunii,„,  [  ca»e(tc*i,  ku\), 


ca»ekELSE  unit^ESAC]  =^CC]=> 

•,  cate(kctk,kuk)},kunitouty-  ktypeout,  E' 


CC2 


E{  I-  [unit,]  U  f=>  kuniti :  ktype,,  E,  +  k  ForAll  »6  {!..&} 


E\  P  [(until, •••.untii)]  =( CC  |=> 

Unit  Tuple  ([kunit  k,  kunit  k]):  Type  Tuple  ([ktype ttype^]),  Ek  +  i 


CC3 


Scope-Begin  (E)  =  E i 

E,  P  [siep,]  =4 SP  j=>  Ei  +  i  ForAll  t€  {l..fc-l} 

Ek  P  [unit]  =j  U  j=>  kunit:  ktype ,  Ek  +  } 

Not- Local- Type  (ktype,  E  k  +  i)  Check- Joins  (E  k  +  i)  Scope-End  ( E ,  .E*  +  i)  =  £' 

E  t-  [BEGIN  stepi  ■  ■  •  steph.iOUTPUT  unit  END ]  =j  CC  |=>  kunit:  ktype,  E' 


CC4 


E  P  [  ()  ]  ={CCJ=>  unitvoid:  typevoid,  E 


SP1 


Scope-Fn-Begtn(E)  = 


El  P  Jiypedec]  ={TDJ=>  E2 


Scope-Fn-End(E,  E2)  =  E' 


E  (-  [iypedecj  =4  SP  [=^  E' 


SP2 


Scope-Fn-Begin(E)  —  E\ 
E\  I-  [fndec]  =  FD  =>  E2 


Scope-Fn-End(E ,  Ej)  =  E' 


E  P  [fndec]  =fSP~k  E' 


SP3 


E  t-  [unti]  =j  U  [=>  kunit:  ktype,  E' 


E  P  [ LET  sxgnalname  =  unit.]  =)  SP  j=> 

Add-Signal  (  «igna]dec(stjna/name,  ktype,  kunit),  joined,  E') 


SP4 


Find-Fn  ( fnname ,  E)  =  fnno 
ktypein  =  (E  .fndec)\fnno].inputiype 
ktype  out  =  (E  .fndec)\fnno].outputtype _ 

E  P  [MAKE  fnname:  tignalname.]  =j  SP  h=> 

Add-Signal  (  aignaldec (signalname,  ktype out,  in*tance(/hno,  unit query( ktype, n))),  unjoined,  E) 
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SPS 


E  h  [unit]  =|  U  |=>  kunit:  ktype,  E' 

Find- Unjoined  (tignalname,  E)  =  fnno 
Find- Signal  (tignalname,  E)  =  signal (tignalno):  ktype ovt 
(E .fndec)\fnno].inputtype  T  [=  ktype 

E  I-  [ JOIN  unit — *  tignalname .]  =(  SP  f=> 

Add-Join  (  *ignaldec(iijnainame,  ktypeeut,  inctanc e(fnno,  kunit)),  lignalno,  E1) 


3.5.7  Built-In  Functions 

Built-in-functions  (function  bodies)  are  defined  to  be 

functionbody  ::=  unit 

|  REFORM 
|  BIOP  biopname 

|  DELAY  (  initialvalue,  ambigtime,  ambigvalue,  delaytime) 
|  IDELAY  (  initialvalue,  delaytime  ) 

|  SAMPLE  (  interval,  initialvalue,  skewtime  ) 
j  RAM  (  initialvalue  ) 

with  the  following  transformations 


Bll 


TypeTuple(Flatten(ktypein))  =fT~j=  TypeTuple(Flatten(ktypeout)) 


E  h  [REFORM]  {ktype in,  ktype  Olif  }  4bTV  reform 


BI2 


Find-Biop(biopname,  ktype, n,  ktype  out)  =  biop  (biopname) 


E  I-  f  BIOP  biopname  J  {ktype  m,  ktypeoul} 


hiop(biopname) 


BI3 


E  (-  [iruhalvaiuej  =j  C  p  kconst,:  ktype, 

E  h  (amityvoluej  =j  C  p  kconst a:  ktype a 
ktype, n  =Tt~1=  ktypeou,  =|t|=  ktype,  =fx~|=  ktype, 
ambigtime<  delaytime 


E  t-  [DELAY  (initialvalue,  ambigtime,  ambigvalue,  delaytime)]  {ktype in ,  ktype out}  =15! 
delay (kconit,,  ambigtime,  kconit,,  delaytime) 


BI4 


E  h  [imtia/ra/uej  =^Cj=>  kconst:  ktype  ktype  =fT~l=J  ktype, n  ={t]=  ktype out 

E  I-  [IDELAY(tnitialvalue,  delaytime )]  {ktype in,  ktype eut) 
idelay  (tconjt,  delaytime) 


E  I-  [initialvalue J  =fc~l=>  kconit:  ktype 
•interval<  ikew<  interval  ktypein  =(~tT=  ktype  out  jTfc  ktype 

E  H  [SAMPLE  (interval,  initialvalue,  eieui))  {ktype, n,  ktype  cut}  =j  BI  ^=> 
sample( interval,  kconit,  ikew) 


ELLA  Static  Semantics 


49 


E  h  [initiaholue]  =j  C  p  kconst;:  ktype  j 
ktypeln  =  kypet([ktypt  dafa ,  ktype ^ tvrxteaddrtii  i  ktype rtaiaidrtu  i  ^^yPetoMte«n«i/t]) 
ktypeiata  =©=  ktype  out  =ffl=  ktype j 
Find- Integer- Type  (ktype vmttadllTti,)  =  .  ,  lb,  ub 
Find-Integer-Type  (ktype  =  .  ,  lb,  ub  lb  =  1 

_ Check-Two-Val  (Get-TypektypevriUtnakit) _ 

E  h  {i?i4M(tn»itaica/wc)J  {ktype  {n,  ktype  out}  =)  BI  =>  ram(kconsti) 


3.5.8  Type  Declarations 
Type  declarations  are  defined  as 


typedec 


TYPE  typename  =  typeornew. 


typeornew 


typealt 


NEW  tagname  /  (  lwb  ..  upb  ) 

NEW  (  typealt!  I  •  •  •  I  typealt*  ) 
NEW  tagname  (  'charj  |  •  •  •  |  'char*  ) 

altname  &  type 
alt  name 


with  transformations  on  them  by 


E  h  [new)  =  NW  =>  knew,  E' 


E  H  {TYPE  typename  =  new.  J  -  TD  =>  Add-Type  (  typedec( typename,  knew),  E') 

jjj _ E  I  type]  ktype _ 

E  h  [TYPE  typename  =  type.  ]  TD  j=>  Add-Type-Name  (typename,  ktype,  E) 


lwb<  upb 

E  t-  [NEW  tagname /(lwb.. upb)]  =j  NW  [=> 
ellaint( tagname,  lwb,  upb),  Add-Tag  (tagname,  E) 


E,  H  [ typealti J  TA  =>  E,  +  i  ForAll  i€  {!..&} 


Ei  H  [NEW  (typealti  |  •••  |  typealt*))  =|NW  |p  tags([t!,- •  t*)),  Ek  +  i 


char ^  char j  ForAll  i,j€  {!••&}  j 

E  H  [NEW  tagname(' chari  |  •  •  •  |  'cfcor*)J  =j  NW  }=> 
chart( tagname,  [cAarj,  •  •  • ,  cfcar*]),  Add-Tag  (tagname,  E) 
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_ E  h  [type}  4T  =»  ktype 

E  I-  [altname ktype]  ={Ta}=>  tag {altname,  ktype),  Add-Tag  {altname,  E) 


E  h  [altname J  TA  \=>  tag{altname,  {nil}),  Add-Tag  {altname,  E) 


3.5.9  Function  Declarations 


Function  declarations  are  given  by 


FN  fnname  =  input  — *  type  :  functionbody. 


(  typej  :  signalnamej,,  •  •  •,  type*  :  signalname*  ) 


and  the  transformations  on  them  by 


E  t-  [input]  =j  IN  (=>  ktype,nvutt,  E' 

E' t -  [ type 1?T)=>  ktype  out 
E‘  (-  [unit]  =|  U  ]=>  tun  it:  ktype,  E" 

_ ktype  o»t  =Tf]=  ktype _ 

E  h  [FN  fnname  =  input — >  type:  u nit.  ]  =  FD  => 

Add-Fn  (  fndec(/nnume,  ktype, npvt,,  E"  .ugdec,  ktype  out,  kumt),  E,  E") 


E  t-  [input]  =|In1=>  ttype ,npu„,  E' 

E'  h  [type]  =|  T  j=>  ktype <,u( 

E'  I-  [iuittin]  {ktype inputn  ktype}  =  BI  =»  kbuiltin 

E  t-  [FW  fnname  =  input—*  type:  builtin.  ]  =  FD  => 
Add-Fn  (  thdec(/nname,  ityp«, itypeet(|,  iiuiitin),  E,  E') 


Ei  h  [typ«,]  JfU  ktype ,  ForAll  «€  {1  -  k} 

Add-Signal(  *ignaldec(  jiyno/name itype;,  input),  joined,  Ei)  =  E,+  j  ForAll  i€  (l.t) 

Fi  I-  I(!yp«i:  tignalnamej,  ■■  ■ ,  typek:  Myna/name*)]  IN  (=» 
Typ*Tuple([ktypei,  -  ■  ■  ,klypetk]),  Ek  +  1 


E  I-  [  ()  |  ==j  FN  (=>  typevoid,  E 
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3.5.10  Closure 


A  Closure  is  defined  to  be 

declaration  ::=  typedec 

|  fndec 

closure  ::=  declaration!  •  •  •  declaration* 

with  the  following  transforms 


D1 


E  b  [ typedec J  ={TD>  E' 


D2 


E  b  [typedec]  =)  D  |=»  E' 
E  t-  [fndec]  =(  FD  E' 


E  b  [fndec]  =  E' 


CL 


E,  b  [declaration  i\  =|Dp  Ei  +  i  ForAll  t'€  {!..&} 


E\  b  [ declarationi  •  •  -  declaration^  J  =  CL  p-  Ek  +  j 


KERNEL 


InitialEnv  b  5ciosure|  =  CL  (=>■  E 


|c/ostire|  =j  KERNEL  |=>  (E. typedec,  E. fndec) 


3.6  Extracting  the  Type  of  a  Kernel  Structure 

This  section  gives  an  example  of  how  the  Kernel  can  be  used  to  find  information  about  a  circuit 
description.  Three  functions  are  defined  which  extract  the  type  information  from  constants, 
constant  sets  and  unit  expressions. 


3.6.1  Constant  Type  Value 

This  section  defines  the  function  Type-Of-Const  for  getting  the  Type  of  a  constant  expression 


Type-Of-Const  ikConst  — >  kType 

Type-Of-Const(const)  A 
cases  const  of 
enum  (typeno,-) 

•tring(  typeno,  (toy  i,  •  •  •,  tay„]) 
conststring(*tze,  c) 
con*ts([ci,  •  •  ■ ,  c„]) 

constassoc(  enum(  typeno, .), .) 
constquery(  type) 
eonstvoid 


typeno  (typeno) 

stringtype(n,  typeno( typeno)) 
«tringtype(#ize,  Type-Of- Const (c)) 
type*!! Type-Of-Const  (ci), 

•  ••,  Type-Of-Const  (cn)]) 
typeno  (typeno) 
type 

typevoid 


end 
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3.6.2  Constant  Set  Type  Value 

This  section  defines  the  function  Type-Of-Constset  for  getting  the  Type  of  &  constant  set  ex 


pression 

Type-Of-Constset  -.kConstset  — ♦  kType 

Type-Of-Constset(constset)  ^ 
cases  constset  of 
enum(  typeno,-) 
string( typeno,  [ta^,  •  •  ■ ,  ta$„]) 
constsetalts([c,  •  •  •  ]) 
constsetstring( size,  c) 
constsets([ci,  •  •  • ,  c„]) 

constsetassoc(  enum (typeno,-),-) 
vonstsetany  (type) 

end 


typeno  (typeno) 

stringtype(n,  typeno  (typeno)) 
Type-Of- Constset  (c) 

•tringty pe( size,  Type-Of- Constset ( c ) ) 
types ([ Type- Of- Constset  (cj), 

•••,  Type- Of- Constset  (cn)]) 
typeno(  typeno) 

type 


3.6.3  Unit  Type  Value 

This  section  defines  the  function  Type-Of-Unit  for  getting  the  Type  of  a  unit  expression.  The 
fndec  sequence  passed  in  is  the  sequence  of  fndecs  in  the  closure  up  to  and  including  the 
declaration  of  the  outermost  function  in  which  the  unit  expression  occurs. 


Type-Of-Unit  :  kFndec*  x  kUnit  — <■  kType 


Type- Of- Unit(f,  unit)  & 


cases  unit  of 
enum  (typeno,  -) 
string  {typeno,  [tagi,  •••,<«!$„]) 
conc(.,  type) 
unitstring(stze,  u) 
units([ui,  ■•■,«»]) 

instanc  e(/nno, .) 

unitassoc(  enum(  typeno, .), .) 

extract  (u , ,) 

signal(  signalno) 

index( . , . ,  outputtype ) 

trim(  outputtype ) 

dy  index  ( . , . ,  outputtype ) 

rep  lace  ( u 

unit  query  (type) 

caseclause(.,.,u) 

unit  void 


— ►  typeno  (typeno) 

-*  stringtype(n,  typeno  (typeno)) 

— *  type 

— >  stringtype(s:ze,  Type-Of-Unit  (/,  u)) 
-»  types([ Type-Of- Unit  (/,  «i), 

•  ••,  Type-Of-Unit  (/,un)]) 

— »  flfnno],  outputtype 
— *  typeno(  typeno) 

-*  Type-Of-Unit  (/,  u) 

—>  (/ [len  / ] .  signaldec)  [  signalno] .  type 
— *  outputtype 
— t  outputtype 
— »  outputtype 
-*•  Type-Of-Unit  (/,  u) 

-*  type 

—  Type-Of -Unit{f  ,u) 

— »  typevoid 


end 
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3.7  A  Formal  Transformation  Example 

In  this  section  we  give  an  example  of  the  transformation  rules  applied  to  a  simple  Core  ELLA 
description.  Through  this  example  the  reader  will  see  how  the  scopes  and  types  are  incorporated 
into  the  environment  and  how  the  information  is  used. 

We  consider  the  following  Core  ELLA  description 

TYPE  bool  «  NEW  (t  |  f). 

FI  I0R  *  (bool: ini,  bool:in2)  ->  bool: 

CASE  (ini,  in2)  OF 
(f ,t) :f , 

(t.f):*, 

(t.t):f, 

ELSE  t 
ESAC. 


FN  A  =  (bool: ini,  bool:in2)  ->  bool: 

BEGIN 

LET  ip  *  (inl,in2). 

FN  B  =  (bool:ipl,  bool:ip2)  ->  bool:  N0R(ipl , ip2) . 
MAKE  B:b. 

JOIN  ip  ->  b. 

OUTPUT  b 
END. 


with  the  initial  environment 
E  =  env([], 

For  brevity  the  constructor  name  env  will  be  omitted  from  the  declarations  of  environments 
throughout  this  section. 


We  start  be  applying  the  transformation  rules  necessary  for  the  type  declaration  ‘bool’  and 
then  proceed  to  add  the  functions  ‘NOR’  followed  by  ‘A’.  Throughout  this  example  expressions 
which  are  numbered  on  the  right  hand  side  are  expressions  which  need  to  be  satisfied,  their 
evaluation  being  shown  by  expressions  with  numbers  on  the  left  hand  side. 


3.7.1  Type  Declaration 


[TD1] :  E  H  lAT£W(t  |  /).J  =|NWk  knew,  E, 
E  H  [TYPE  bool  =  NEW(t  |  /).  ]  ={TD 


Add-Type(  typedec(6ooi, knew),  £2) 


(1) 

(2) 


(1)  :  E  h  jtj  =fTA~k  tvu  Ei 


(3) 
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Ex  H  [f]  =Tta]=>  ty2,  E2 

E  h  [NEW(t  I  f).\  MNWk  tags([/yi,  ty2]),E2 
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(4) 

(5) 


(3)  :St-M  =|TAk  tag(t, {}), E 


where 

Ei  =  Add- Tag  (  t,  E) 


Ei  =  ([],  0,  0,  0,  {},  {},  0  -  consttag(l)},  {},  {},  {},  {},  {}) 


Also 

(4)  :  Ex  I-  1/1  =TtA~W  tag(/,{}),£2 

where 

E2  =  Add- Tag  (f,  Ei) 


i.e. 

Ez  =  ([],  0.  0.  {},  {},  {},  {f  -*  consttag(l),  t  «  consttag(l)},  {},  {},  {},  {},  {}) 


(5)  :E^[IfEW(t\f)]  4NWW  tags([  tag(t,  {}),  tag(/,  {})]),  £2 


which  gives 


(2)  :  E  h  [TYPE  bool  =  NEW(t  \  f).  ]  =|_TD_p  £3 


where 

E3  =  Add-Type{  typedec(6oo/,  tags([  tag(t,{}),  tag(/,  {})])),  E2) 


E3  =  (  [  typedec( 600/ ,  tags([  tag(l,{}),  tag(/, {})]))], 

0. 

0, 

0, 0, 

{},  {bool  *-♦  typeno(l),  /  *-♦  con*ttag(l),  1  •-»  consttag(l)}, 

{},{}, 

{},{},  0 

) 


we  are  now  in  the  position  where  we  can  apply  the  transformations  to  the  function  NOR: 
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3.7.2  Function  Declaration 

In  order  to  apply  rule  [FD]  to  function  NOR  we  need  the  following  rule  applications 


[FDl] :  E3  I-  [(bool:  ini,  bool :  in2)]  =jlN  !=»■  ktype,, E3  (1) 

Es  t-  [600/]  ={T>  ktype0  (2) 

Es  h  I CASE  ..  ESAC.]  ={u}=>  kunit :  ktypeu,  £6  (3) 

ktype,  4tT=  ktypeu  (4) 

E3  h  [FN  NOR  ...1  =fFD~U  £e  = 


Add-Fn(  fndee(NOR,ktypei,  Et.sigdec,  ktype,,  kunit),  E3,  Es)  (5) 


Now 


(1)  :  E3  h  [bool]  =4t~1=>  kiype  (6) 

Add-Signal(  signaldec(tnl, ktype,  input),  joined,  E3)  =  £4  (7) 

Add-Signal(  signaldec(tn2,  ktype,  input),  joined,  £4)  =  £5  (8) 

£3  h  [(bool:  ini,  bool:  in2)]  =[lN]=>  TypeTuple[ktype,  ktype],  £5  (9) 


(6)  :  £3  h  [bool]  Find-Type(bool,  £3)  =  typeno(l) 


(7)  :  Add-Signal{  signaldec(inl,  typeno(l),  input),  joined,  £3)  =  £4 


where 


E4  =  (  [  typedec(bool,  tags([  tag(t,{}),  tag(f, {})]))  ], 

D. 

[  signaldec(inl,  typeno(l),  input)  j, 

0.  {). 

{},  {bool  <-*  typeno(l),  /  •->  consttag(l ),  t  consttag(l)}, 
{},  (ini  *-»  sig(l,  joined)} 

{},{}.{} 

) 


(8)  :  Add-Signal(  signaldec(in2,  typeno(l),  input),  joined,  £4)  =  £5 


where 


Es  =  (  [  typedec(bool,  tags([  tag(t,{}),  tag(f, {})]))  ], 

[], 

[  »ignaldec(inl,  typeno(l),  input),  «ignaldec(in2,  typeno(l),  input)  ], 

0.  {}. 

{},  {bool  >-*  typeno(l),  f  *-*  eonsttag(l),  t  *-»  consttag(l)}, 

{},  {in2  >-»  iig(2,  joined),  ini  •-»  *ig(l,  joined)}, 

{MM} 

) 


the  premises  of  IN  are  now  satisfied,  thus 
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(9)  :  E3  h  [(too/:  ini,  bool:  in2)l  4lN]=>  types([  typeno(l),  iypeno(l)]),  £t 

(2)  :  Es  I-  [too/]  =TtV  typeno(l) 


The  evaluation  of  the  CASE  clause  can  now  proceed 


(3)  :  £g  h  [(ini,  in2) 


£s  I- [(/,<):/]  =  CA 
Es  t-  [(*,/):/]  kCA 
H  l(<» <)Lf]  =<CA 
Es  H  [t]  =juV  kunit 
ktypeci  =m=  ktypec2 
ktypevi  =Tt 


HU  F»  kunit in:  ktypein,  Et 

kcs i,  bi\:  ktypeci,  ktype ui,  Es 
kcs 2,  ku3:  ktypeci,  ktype u2,  Es 
kcs3 ,  ku3:  ktypec3,  ktypeu3,  Es 
ktype 0,  Es 
=fT~k  ktypec3 

ktypeu 2  HT  |=  ktypeu 3  =Tt1=  ktype » 


Disjoint(kcsi,kcs3)  A  Disjoint(kcs3,  kcs3)  KDisjoint(kcsi,  kcs3) 
E3  I-  [CASE  ..  ESAC]  HCC| 


caseclause(Aun:t,n,  [  cnse(kcsx,kui),  case( kcs2,  ku2), 
case(kcs3,ku3)},  kunit „):  ktype0,  Es 


(10) 

(11) 

(12) 

(13) 

(14) 

(15) 

(16) 
(17) 


(18) 


Now 


(10)  :  Es  H  { *«  1 1  =  _Uj 

Es  I-  [in2]  =£tT 


Es  V-  [(ini,  in2)]  H 


kunit  i: 
kunit3: 


ktype u  Es  (19) 

ktype 2,  Es  (20) 

Unit  Tuple[kuniti,  kunit  3):  TypeTuple[ktypex,  ktype  2},  Es  (21) 
Es  [(ini,  in2)|  HU  Unit Tuple\kunitx,  kunit 2]‘-  TypeTuple[ktypex,  fc/t/pe2],  Es  (22) 


CC 


(19)  :  Es  H  [ini]  ={u]=>  signal(l):  typeno(l),  £5 

(20)  :  Es  I-  [in 2]  ={u}=>  «ignal(2):  typeno(l),  £5 


thus 


(21)  :  £5  H  [(ini,  tn2)]  ={££]=► 

units([  signal(l),  signal(2)]):  types([  typeno(l),  typeno(l)]),  Es 


(22)  :  £5  h  [(ini, in2)]  ={u}=> 

units([  signal]  1),  signal(2)]):  types([  typeno(l),  typeno(l))),  £5 


For  evaluation  of  case  arm  alternatives  we  need 

(11)  :  Et  H  [(/,  Q]  HCSh  kc$i:  ktypecx 
Es  [f]  =fu~k  kut:  ktypeuu  £5 

Es  I"  [(/,<):/]  =jCA  k  kcsu  kux:  ktypecx,  ktypeu j,  £$ 


(23)  :£*•“[/]  HCS  k  kcx:  kti 
Es  (•  [<]  =  CS  =>  kc3:  kt3 

Es  >-  [(/,  01  4CS  k  ConsUetTuple([kci,kc3]):  TypeTuple([ktukt2]) 


(23) 

(24) 

(25) 

(26) 

(27) 

(28) 


L 
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(26)  :EshLf]  =fCSk  enum(l,2),  typeno(l) 

(27)  :  Es  h  =jCS  (=»  enum(l,l),  typeno(l) 
combining  these  last  two  results 

(28)  :  Es  h  [(/,  Q]  =fc?k  constsets([  enum(l,2),  enum(l,  1)]):  types([  typeno(l),  typeno(l) 
(24)  :2?sl-l/l=®>  enum(l,2):  typeno(l),  Es 


thus 


(25)  :  Es  I(/»t):/)J  ={cX 


con8tsets([  enum(l,2),  enum(l,l)]),  enum(l,2): 
types([  typeno(l),  typeno(l)]),  typeno(l),  Es 


Similarly 

(12)  :  E 5  H  [(t, /)••/)!  =fc A ]=>  constsets([  enum(l,  1),  enum(l,2)]),  enum(l,2): 

types([  typeno(l),  typeno(l)]),  typeno(l),  Es 


(13)  :£st-[(t,  <):/)]  =|CA 


constsets([  enum(l,l),  enum(l,l)j),  enum(l,2): 
types((  typeno(l),  typeno(l)]),  typeno(l),  £5 


the  ELSE  clause  of  the  CASE  statement  gives 

(14)  :  E5  h  [<]  =[U}*  enum(l,l):  typeno(l),  Es 

(15) ,  (16)  and  (17)  are  obviously  true  and  hence  we  have 

(18)  :  Es  h  [CASE....ESAC]  =fccV 

caseclause(  units([  signal(l),  signal(2)]), 

(  ca«e(  constsets([  enum(l,2),  enum(l,l))),  enum(l,2)), 
case(  constsets([  enum(l,l),  enum(l,2)]),  enum(l,2)), 
case(  constsets([  enum(l,l),  enum(l,l))),  enum(l,2))j, 
enum(l,  1)):  typeno(l),  Es 

(*')  =  typeno(l)  ={t}=  typeno(l) 

Bringing  the  above  results  together  foT  the  complete  function  gives: 

(5)  :  E3  h  l FN  NOR  =  ....]  =fFD~k  E« 


where 
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E«  =  Add-Fn  (  fndec  (NOR,  type»([  typeno(l),  typeno(l)]), 

[  aignaldec(inl,  typeno(l),  input), 
signaldec(in2,  typeno(l),  input)], 
typeno(l), 

caseclauae(  uniti([  aignal(l),  aignal(2)]), 

[  caae(  conataeta([  enum(l,2),  enum(l,l)]),  enum(l,2)), 
caae(  conataeta([  enum(l,l),  enum(l,2)]),  enum(l,2)), 
caae(  conataeta([  enum(l,l),  enum(l,l)]),  enum(l,2))], 
enum(l,l)), 

E3,  Es  ) 


E«  =  (  [  typedec(booI,  taga([  tag(t,{}),  tag(f, {})]))], 

(  fndec(NOR, 

types([  typeno(l),  typeno(l)]), 

(  aignaldec(inl,  typeno(l),  input),  aignaldec(in2,  typeno(l),  input)], 
typeno(l), 

caseclause(  units([  aignal(l),  aignal(2)]), 

[  case(  constsets([  enum(l,2),  enum(l,l)]),  enum(l,2)), 
case(  const  set  s((  enum(l,l),  enum(l,2)]),  enum(l,2)), 
case(  constsets([  enum(l,l),  enum(l,l)]),  enum(l,2))], 
enum(l,l)) 

] 

u. 

{},  {NOR  -  1}, 

{},  {bool  —  typeno(l),  f  —  consttflg(l),  t  —  consttag(l)}, 

{},{}, 

{MM} 

) 


3.7.3  Function  Declaration  with  Scoping 

We  now  add  to  the  above  environment  the  function  ‘A’  which  will  demonstrate  the  scoping 
mechanism  of  the  transformation  rules.  For  convenience  we  reproduce  here  the  definition  of 
function  ‘A’ 


FI  A  ■  (bool: ini,  bool:in2)  ->  bool: 

BEGII 

LET  ip  *  (inl,in2). 

FI  8  *  (bool:ipl,  bool:ip2)  ->  bool:  IOR(ipl ,ip2) . 
HAKE  B:b. 

JOII  ip  ->  b. 

OUTPUT  b 
EID . 


Assuming  the  result  of  the  previous  section,  the  starting  environment  for  the  transformation 
process  of  function  ‘A’  is: 
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£  =  (  [  typedec(bool)], 

[  fadec(NOR)], 

0. 

{},  {NOR  -  1}, 

{},  {bool  — »  ,  f - *  ,  t— *  } 

{}.  O 

{>.  0,0 

) 


:  Type  declarations 
:  Fn  declarations 
:  Signal  declarations 
:  Fn  mappings 
:  Type  mappings 
:  Signal  mappings 
:  Out  of  scope  Nms  and  Fns 


In  order  to  simplfy  reading  whenever  *  bool’  is  used,  i.e.  in  a  non-syntactic  position,  it  should 
be  taken  to  be  equal  to  *  typeno(l)’.  Also  the  ‘bool’  type  declaration  and  the  NOR  function 
declaration  have  been  abbreviated  to  only  the  first  field  of  the  structures.  The  name-mapping 
field  for  the  type  declaration  has  also  be  abbreviated  to  only  contain  the  domains. 


The  rule  for  adding  function  ‘A’  to  the  environment  is  given  by  [FDl]  which  requires  the 
following  to  be  satisfied 


E  h-  [(6oo/:  ml,  bool:  in2)]  =jlN  k  ktype,,  E' 

(1) 

E1  h  [5oo/]  ={t}»  ktype„ 

(2) 

E'  (-  [BEGIN  ..  END. ]  ={¥}=>  kunit:  ktypeu ,  E" 

(3) 

ktype 0  =  T  =  ktype u 

(4) 

E  h  [FN  A  ...]  =fFD]=»  E'"  = 

Add-Fn(  fndec (A,  ktype,,  E" .sigdec,  ktypeD,  kunit),  E,  E'1)  (5) 


We  now  proceed  to  evaluate  the  different  expressions  in  order  to  arrive  at  the  final  environment 
of  E'". 


(1)  :  ktype ,  =  types([  bool,  bool]) 

E'  =  (  [  typedec(bool)], 

[  fndec(NOR)], 

[  signaldec(inl,  bool,  input),  signaldec(in2,  bool,  input)] 
{},  {NOR  — »  1} 

{},  {bool  —  ,  f-*  ,  t—  } 

{/,  {in2-»  «ig(2,  joined),  ini-*  «ig(l,  joined)} 

0,0,0 

) 


(2)  :  ktype,  =  Find- Type(bool,E')  =  bool  (=  typeno(l)) 


Scope- Begin{E')  =  E 1 

(6) 

El  h  [LET  ip  —  (tnl,tn2).]  =j  SP  j=>  E2 

(7) 

E2  t-  (FN  B  =  ...J  =TSPU  E3 

(8) 

£3  h  [MAKE  B :  6.]  JsPk  EA 

(9) 

E4  h  [JOIN  ip  -*  t.]  =jSPk  £5 

(10) 

£5  H  |b}  =fu]=>  kunit  :  ktype u  ,  £6 

(11) 

Check- Joins  {E  6) 

(12) 

Scope-End(E\  £6)  =  E" 

(13) 

£b  [ecrutaei:  unit]  =j  CA  kconstsel,  kvnit:  ktypeconst,  ktype ,  E' 
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(6)  :  El  =  (  [  typedec(bool)], 

[  fndec(NOR)], 

[  *ignaldec(inl,  bool,  input),  *ignaldee(in2,  bool,  input)], 

{NOR-1},  {} 

{bool—,  f— ,  t— },  {} 

{in2— ,  ini—},  {} 

{},{}.  0 

) 

(7)  :  El  b  [(ini,  m2)]  =fu~|=>  kunit  :  ktype,  El'  (14) 

ElhlLETip  =  (inl.in2).l  =j  SP  )=>  Add-Signal{  *ignaldec(ip,  ktype,  kunit), 

I  '  -  joined(  EV)  (!5) 


(14)  :  El  b  [ini]  =ful=»  kunit  i  :  ktype i  ,  £11 
£11  b  [in2]  =^U  h-  kunitj  :  ktypet  ,  £12 
£1  b  [(ini,  in2)1  =fu~k  UnitTuple([kunitu  kunit 2})  : 

Type  Tuple  ([ktypei,  ktype  2])  ,  E 12 


(16)  :  Find-Signal(inl,  El)  =  let  Find-Sig-Nm(inl,  £1)  =  sig(l,  joined)  in 

signal(l),  bool 

£11  =  £l 

£1  b  [ini]  =TuW  signal(l):  bool,  El 


(17)  :  £1  b  [in2]  =fuV  signal(2):  bool,  £1 


(18)  :  £1  b  [(inl,in2)]  =jul=» 


UnitTuple(\  signal)  1),  signal(2)]):  Type Tuple({  bool,  bool]),  £1 
=  units([  signai(l),  signal(2)])  :  types((  bool,  bool])  ,  £1 


(15)  :  Add-Signal{  signaldec(:p,  types([  bool,  bool]), 

units([  lignal(l),  signal(2)])),  joined,  £1) 

=  let  Len  =  2  in 

let  SigName  =  ip  in 

£2 


£2  =  (  [  typedec(bool)], 
f  fndec(NOR)], 

[  »ignaldec(inl,  bool,  input),  *ignaldec(in2,  bool,  input), 

•ignaldec(ip,  types([  bool,  bool]),  units([  signal f  1 ) ,  tignal(2)])) 

]. 

{NOR-1},  {} 

{bool—,  f— ,  t  — },  {} 

{in2-,inl-},  {ip-  *ig(3,  joined)} 

{}.{}>{} 

) 
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Scope-Fn-Begin(E2)  =  E2' 

(19) 

E2'  I-  [FN  B  ...\  4FDV  E2" 

(20) 

Scope-Fn-End(E2,  E 2")  =  E3 

(21) 

E2  1-  {FN  B  ...J  =jSPk  El 

(22) 

(19)  :  E2'  =  ([  typedec(bool)], 

( fhdec(NOR)], 

0. 

{NOR-*l},  {} 
{bool-*,  f-*,  t-*},  {} 
{}*  {}* 

{}.  {}*(} 

) 


(20)  :  E2'  h  [( bool :  ip  1,  bool:  ip2 )|  =jlN  }=?»  ktypd,  E2'l 
E2'l  I-  [too/]  =lT)=>  ktype0 

E2'l  h  [NOR{ipl,ip2)]  ={u}=>  kunit:  ktypeu ,  E2'2 
ktype0  =Tt~]=  klypex 


E2'  I-  f-FW  B  ...]  =)FD  Add-Fn(  tndec(B,  ktype,,  E2'2.sigdec,ktype0,  kunit), 

E2\  E2'2) 


(23) 

(24) 

(25) 

(26) 

(27) 


(23)  :  ktype,  -  [  bool,  bool] 

E2'l  =  (  [  typedec(bool)], 

[  fndec(NOR)], 

[  signaldecfipl,  bool,  input),  signaldec(ip2,  bool,  input)], 
{NOR-,1},  {} 

{bool—*,  f-*,  t— },  {} 

{},  {ipl-  sig(l,  joined),  ip2— *  sig(2,  joined)}, 

{MM} 

) 


(24)  :  ktype 0  =  bool 


(28) 

(29) 

(30) 

(31) 


(25)  :  £2'1  h  [(ipl,  *>2)j  ={u}=>  kunit :  ktype,  E2'V 
fnno  =  Find-Fn(NOR,  E2'l) 

(E2'l  .fndec  )[/nno] .  inputtype  =Tt~]=  ktype 

E2'l  h  [NOR{ipl,ip2)]  =ju]=*  instance(/nno, kunit): 

(E.fndec)\fnno].outputtype,  E2'\' 


(28)  :  E2'\  H  [(ipl,  *p2)j  =Tu]=»  uniti([  «ignal(l),  «ignal(2)]):  types([  bool,  bool]),  E2'l 

(29)  :  fnno  =  1 

(30)  :  type«([  bool,  bool])  ={f]=  ktype  (=  type*([  bool,  bool])) 


€2 
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(31)  :  £2'1  (-  I^0*(tpl,*p2)l  =GD=>  instance(l,  units([  »ignal(l),  «ignal(2)])):  bool,  E2'l 
(26)  :  ktypet  (=  bool)  =j~f~l=  ktypeu  (=  bool) 


(27)  :  E2  h  [FN  B  ...]  FD  =>  Add-Fn(  fndec  (  B, 

types([  bool,  bool]), 

[  signaldec(ipl,  bool,  input), 
>ignaldec(ip2,  bool,  input)], 
bool, 

^  instance(l,  units([  •ignal(l),  signal(2)])) 
E2\  E2'l  ) 

=  E2" 


E 2"=  (  [  typedec(bool)], 

[  fndec(NOR), 
fndec(B, 

types([  bool,  bool]), 

[  signaldec(ipl,  bool,  input),  signaldec(ip2,  bool,  input)], 
bool, 

instance(l,  units([  signal(l),  signal(2)])) 

]> 

[], 

{NOR— *1},  {B— >2} 

{bool—*,  f— *,  t-*},  {} 

{>*{>* 

{}*{},{} 

) 


(21)  :  Scope-Fn-End{E2,  E2")  =  £3 

£3  =  (  [  typedec(bool)], 

[  fndec(NOR), 
fndec(B, 

types((  bool,  bool]), 

[  signaldec(ipl,  bool,  input),  signaldec(ip2,  bool,  input)], 
bool, 

instance(l,  units([  «ignal(l),  «ignal(2)])) 

]> 

[  «ignaldec(inl,  bool,  input),  »ignaldec(in2,  bool,  input), 

^  »ignaldec(ip,  types([  bool,  bool]),  units([  »ignal(l),  «ignal(2)])) 

{NOR— *1},  {B— *2} 

{bool—*,  f-^,  t^},  {} 

{in2— ,  ini  -*},  {ip-^  «ig(3,  joined)} 

{}*{}*{} 

) 


(22)  :  E2  H  [Ftf  B  ...]  =TsP~U  F3 
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:  Find-Fn(B,  E3 )  =  fnno  (32) 

ktypei  =  E.  fndec[fnn  o}.  inputty pe,  ktype0  =  E.fndec[fnno).outputtype  (33) 

Eh  \MAKE  B:  6.]  =  SP  =»  Add-Signal(  signaldec (b,ktype, 

instance(/nno, 

unit  query  ( ktype ) ) , 
unjoined,  £3)  (34) 


(32)  :  Find-Fn(B,  E 3)  =  2 


(33)  :  ktypei  =  types([  bool,  bool]),  ktype0  =  bool 

(34)  :  Add-Signal{  signaldec(6,  bool, 

instance(2,  unitquery(  types([  bool,  bool])))),  ui\joined,  £3) 

=  £4 

£4  =  (  [  typedec(bool)], 

[  fndec(NOR), 
fndec(B, 

types([  bool,  bool]), 

[  signaldec(ipl,  bool,  input),  signaldec(ip2,  bool,  input)], 
bool, 

instance(l,  units([  signal(l),  signal(2)])) 

). 

[  signaldec(inl,  bool,  input),  signaldec(in2,  bool,  input), 
signaldec(ip,  types([  bool,  bool]),  units([  signal(l),  signal(2)])), 
signaldec(b,  bool,  instance(2,  unitquery(  types([  bool,  bool])  ))) 

]. 

{NOR— 1},  {B— 2} 

{bool—,  f— ,  t  — },  {} 

{in2— ,inl  — },  {ip—  sig(3,  joined), 

b  —  sig(4,  unjoined)  } 

{MM) 


(10)  :  £4  h  f»j>]  =Tu~k  kunit  :  ktype  ,  £4'  (35) 

Find-Unjoined(b,  £4)  =  fnno  (36) 

Find- Signal {b,  E 4)  =  tignal(signalno)  :  ktype 0  (37) 

E4.fndec\fnno].inputtype  =fT~l=  ktype  (38) 

£4  b  [JOIN  ip  —  6.J  ={  SP  (=»  Add-Join(  signaldec (b,ktypet, 

instanc e(/nno,  kunit)),  signalno,  £4')  (39) 


(35)  :  Find-Signal(ip,  £4)  =  let  Find-Sig-Nm(ip,  £4)  =  §ig(3,  joined)  in 

signal(3),  types([  bool,  bool]) 

£4  h  ftp]  =fu]=>  signal(3):  types([  bool,  bool]),  £4 
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(36)  :  Find-Unjoined(b,  E4)  = 

let  Signo  =  (E4.lclsignamemap)(b).signalno  =  4  in 

let  >ignaldec(&,  bool,  instance(/nno,  unitquery(  types([  bool,  bool)))))  in 
=  (E4.tigdec)[Signo] 
fnno  =  2 


(37)  :  Find-Signal(b,E 4)  =  let  Find-Sig-Nm(b,  E4)  =  sig(4,  unjoined)  in 

signal(4),  bool 

(38)  :  (E4.fndec)[2).inputtype  (=  types([  bool,  bool]))  ^T~l=  ktype  (=  types([  bool,  bool])) 

(39)  :  Add-Join[  signaldec(6,  bool,  instance(2,  signal(3)),  4,  E4)  =  Eb 


E5  =  (  [  typedec(bool)], 

[  fndec(NOR), 
fndec(B, 

types([  bool,  bool]), 

[  signaldec(ipl,  bool,  input),  signaldec(ip2,  bool,  input)], 
bool, 

instance(l,  units([  signal(l),  signal(2)]))  ) 

]. 

[  signaldec(inl,  bool,  input),  signaldec(in2,  bool,  input), 
signaldec(ip,  types([  bool,  bool]),  units([  signal(l),  signal(2)])), 
signaldec(b,  bool,  instance(2,  signal(3))) 

), 

{NOR— 1},  {B— 2} 

{bool—,  f— ,  t  — },  {} 

{in2— ,  ini  —  },  {ip—  sig(3,  joined), 

b  —  sig(4,  joined)  } 

) 

(11)  :  Find- Signal (b,  Eb)  =  let  Find-Sig-Nm(b,  Eb)  -  sig(4,  joined)  in 

signal(4),  bool 

Eb  H  [6]  =j~U~|=>  signal(4):  bool,  E6 


where 
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£6  =  (  [  typedec(bool)], 

[  fndec(NOR), 
fndec(B, 

types((  bool,  bool]}, 

[  signaldec(ipl,  bool,  input),  signaldec(ip2,  bool,  input)], 
bool, 

instance(l,  units{[  *ignal(l),  signal(2)]))  ) 


], 


signaldec(inl,  bool,  input),  signaldec(in2,  bool,  input), 
signaldec(ip,  types([  bool,  bool]),  units([  signal(l),  signal(2)])), 
signaldec(b,  bool,  instance(2,  signal(3))) 


J1 

{NOR— 1},  {B— >2} 

{bool-*,  f— ,  t-*},  {} 

{in2— ,  ini—*},  {ip—  sig(3,  joined), 

b  —  sig(4,  joined)  } 


) 


(12)  :  Check-Joins(EG)  =  True 

(13)  :  Scope-End(E' ,  £6)  =  E" 


E"  =  (  [  typedec(bool)], 

[  fndec(NOR), 
fndec(B, 

types([  bool,  bool.), 

{  signaldec(ipl,  bool,  input),  signaldec(ip2,  bool,  input)], 
bool, 

instance)  1,  units([  signal(l),  signal(2)])) 

l 

j  signaldec(inl,  bool,  input),  signaldec(in2,  bool,  input), 
signaldec(ip,  types)]  bool,  bool]),  units([  signal(l),  signal(2)])), 
signaldec(b,  bool,  instance(2,  signal(3))) 

]* 

{},  {NOR  -  1} 

{},  {bool  — ,  f— ,  t  — } 

{},  {in2—  sig(2,  joined),  ini-  sig(l,  joined)} 

{},{B},{iP,b} 

) 


(4)  :  ktype „  (=  bool)  ={t}=  ktype%  (=  bool) 
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(5)  :  Add-Fn{  fndec(  A, 

types([  bool,  bool]), 

[  *ignaldec(inl,  bool,  input),  *ignaldec(m2,  bool,  input), 
signaldec(ip,  types([  bool,  bool]),  units([  signal(l),  signal(2)])), 
signaldec(b,  bool,  instance(2,  aignal(3))) 

]. 

bool, 

signal(4) 

), 

E,  E" 

) 


E'"  =  (  [  typedec(bool)], 

[  fndec(NOR), 
fndec(B, 

types([  bool,  bool]), 

[  signaldec(ipl,  bool,  input),  signaldec(ip2,  bool,  input)], 
bool, 

instance(l,  units([  signal(l),  signal(2)]))  ) 
fndec(  A, 

types([  bool,  bool]), 

[  signaldec(inl,  bool,  input),  signaldec(in2,  bool,  input), 

signaldec(ip,  types([  bool,  bool]),  units([  signal(l),  signal(2)])), 
signaldec(b,  bool,  instance(2,  signal(3))) 

], 

bool, 
signal(4)  ) 

]. 

I). 

{},  {NOR  — *  1,  A  — *  3}, 

{},  {bool—*,  f—,  t-*} 

{},{} 

{MM} 

) 


3.7.4  The  Kernel  Closure 

The  closure  of  the  Kernel  with  declarations  bool ,  NOR  and  A  is  defined  in  the  following  way 


[CL] 


:  Zx  h  [TYPE  bool  =  ...]  =jTDh» 
Zj  h  [FN  NOR  =  ...1  ={FD  1=> 


Z 3  I-  [FN  A  =  ...]  =|FDk  Zt 
Z i  h  [closure]  =j  CL  [=»  £4 


[KERNEL] 


[closure] 


KERNEL  }=> 


( Z+.typedec ,  Z+.fndec) 


where 
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=  (D.  D,  D,  {}.  {}.  {},  {},  {},  {},  {},  {},  {}) 

S4  =  E"' 

and  thus 

Si.typedecs  =  [  typedec(bool,  tags([  tag(t,{}),  tag(f, {})]))  ] 

Si.fndecs  =  f  fndec{NOR, 

types([  bool,  boolj), 

[  «ignaldec{inl,  bool,  input),  signaldec(in2,  bool,  input)], 
bool, 

caseclause(  units([  signal(l),  signal(2)]), 

[  case(  constsets([  enum(l,2),  enum(l,l)]),  enum(l,2)), 
case(  constsets([  enum(l,l),  enum(l,2)]),  enum(l,2)), 
case(  constsets([  enum(l,l),  enum(l,l)j),  enum(l,2))], 

«num(l,l))) 

fndec(B, 

types(j  bool,  bool]), 

[  signaldec(ipl,  bool,  input),  signaldec(ip2,  bool,  input)], 
bool, 

instance(l,  units([  signal(l),  signal(2)]))  ) 
fndec(  A, 

types([  bool,  bool]), 

[  signaldec(inl,  bool,  input),  signaldec(in2,  bool,  input), 
signaldec(ip,  types([  bool,  bool]),  units([  signal(l),  signal(2)])), 
signaldec(b,  bool,  instance(2,  signal(3))) 

]' 

bool, 

signal(4)  ) 
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4  Conclusions 


In  this  document  we  have  demonstrated  how,  by  means  of  a  set  of  software  transformations 
and  a  set  of  formal  transformations,  any  ELLA  description  can  be  mapped  into  a  set  of  data 
structures.  The  software  transformations  are  a  suite  of  transformations  which  map  ELLA  de¬ 
scriptions  onto  its  Core.  The  formal  transformation  system  define  a  set  of  rules  which  map  Core 
constructs  onto  a  set  of  data  structures  known  as  the  Kernel.  The  mapping  onto  the  Kernel, 
together  with  the  use  of  a  specific  transformation  environment,  provide  a  formal  definition  of 
the  static  semantics  of  the  Core.  Examples  of  both  transformation  processes  have  been  given. 
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A  Glossary  of  Symbols 

Functions 


/:  D\  x  Dj  —*  R 

signature 

f A  ••• 

function  definition 

m 

application 

if  •••  then  •  •  •  else  •  •  • 

condtional 

let  x  =  ••■«»••• 

local  definition 

cose  z  of  •  •  -  else  •  •  •  end 

choice 

pre 

pre-condition 

Composite  Objects 


Object: :  fieldname:  fieldtype 

Record  Object  definition 

fi(E,s  *-»  t) 

change  field  s  of  £  to  hold  t 

»(E,  s  ~  ( E.s  f  0) 

update  field  s  of  E  by  overwriting  with  t 

Sets 


T-set 

finite  subset  of  T 

set  enumeration 

{} 

empty  set 

t  e  T 

set  membership 

T\  n  J2 

set  intersection 

Tj  u  T2 

set  union 

Ti  c  r, 

set  containment 

z 

-1,  0,  1,  ••■} 

Ni 

{1,  2,  •  •■} 

B 

{true,  false} 

Maps 


D  R 

finite  map 

dom  m 

domain 

rng  m 

range 

mi  f  m2 

overwriting 

Sequences 


S* 

finite  sequence 

[*!»•  •*.»*] 

sequence  enumeration 

U 

empty  sequence 

len  l 

length  of  sequence  / 

»l  ~  *1 

concaternation 

t  (i  €  ind*  sequence)  ■  seguence[i]  =  $ 

The  unique  element  of  sequence  which  equals  s 
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Transformation  Environment 
field  selection  in  the  Kernel 
indexing 

invariant  of  environment  E 
formal  transformation 
syntactic  separaters  (  :  ,  ) 
type  equality  in  the  Kernel 
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B  ELLA  Composite  Syntax 

This  appendix  presents  the  ELLA  V6  Syntax1 


B.l  Basic  Notation 


abc  £  Abe 

‘abc’  is  an  element  of  the  set  ‘Abc’ 

b  c 

the  syntax  definition  of  ‘b’  is  ‘c’ 

1 

the  separator  of  alternatives  in  a  syntax  definition 

1 

ELLA  separator  of  alternatives 

intorstring 

an  ELLA  integer  name  or  string  of  printable  characters 

di  •  •  •  d* 

one  or  more  occurrences  of  ‘d’ 

dj,  •  •  •  ,  d* 

one  or  more  occurrences  of  ‘d’  separated  by  ‘,*. 

Note  if  k=l  then  no  is  present. 

di,  •  •  • ,  d*.i 

zero  or  more  occurrences  of  ‘d’  separated  by 

Note  if  k=0  then  no  is  present. 

z  €  Z 

z  £  {  ...  ,-l,  0,  1,  ••  } 

j,k  £  Nj 

j,k£  {  1,  2,  .*•} 

Identifier 

Lower  case  letter 

Fnname 

Upper  case  letter  or  symbol 

Integer 

ELLA  integer  expression 

Constant 

ELLA  constant  expression 

Character 

Any  printable  character 

B.2  Syntactic  Categories 

typename  €  Identifier 

(ELLA  type  name  i.e.  lower  case) 

intname 

6 

Identifier 

(Integer  name  i.e.  lower  case) 

constname 

€ 

Identifier 

(ELLA  constant  name  i.e.  lower  case) 

signalname 

€ 

Identifier 

(ELLA  signal  name) 

tagname 

€ 

Identifier 

(ELLA  tagged  type  name) 

altname 

£ 

Identifier 

(ELLA  enumerated  type  alternative) 

macintname 

6 

Identifier 

(Macro  integer  parameter  name) 

mac  typename 

€ 

Identifier 

(Macro  type  parameter  name) 

repname 

€ 

Identifier 

(Replicator  variable  name) 

nullname 

6 

Identifier 

(An  unnamed  identifier,  given  by  a  blank  space) 

attributename 

£ 

Identifier 

(An  attribute  identifier  name) 

contextname 

£ 

Identifier 

(a  context  name) 

subregionname 

€ 

Identifier 

(a  context  subregion  name) 

fnname 

€ 

Fnname 

(ELLA  function  name  i.e.  upper  case  or  symbol) 

biopname 

€ 

Fnname 

(ELLA  BIOP  name  ) 

alienname 

€ 

Fnname 

(ELLA  ALIEN  name  ) 

index 

€ 

Integer 

(index  of  structure) 

lwb,  upb 

£ 

Integer 

(Lower-bound  and  Upper-bound  of  a  range) 

size 

£ 

Integer 

(Size  of  row  or  string) 

interval 

€ 

Integer 

(ELLA  timing  interval) 

‘Crown  Copyright  ©Controller  HMSO,  London,  1991. 
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ambigtime  6  Integer  (Ambiguity  delay  time) 

delaytime  €  Integer  (delay  time) 

skewtime  £  Integer  (skew  time  value  of  input  data) 

slowtime  £  Integer  (slow  down  factor) 

fasttime  £  Integer  (speed  up  factor) 

initialvalue  €  Constant  (Delay,  Retiming  or  Ram  initialisation  value) 

ambigvalue  €  Constant  (Delay  ambiguity  value) 

char  £  Character  (A  printable  character  i.e.  ‘a’) 

firstchar  £  Character  (First  printable  character  in  a  range) 

lastchar  £  Character  (Last  printable  character  in  a  range) 

string  €  String  (A  string  of  printable  characters  i.e.  ‘abc’) 

B.3  Syntactic  Definitions 
Enumerated 

enumerated  ::=  altname 

|  tagname  /  integer 

|  tagname  'char 

|  tagname  "string" 

Integer 

integer  ::=  integer  dop  integerl 

|  integerl 

integerl  ::=  integerl  +  integer2 

|  integerl  -  integer2 

|  integer2 

integer2  ::=  integer2  *  integer3 

|  integer2  %  integer3 

|  integer3 

integer  3  ::=  z 

|  intname 

j  signalname 

|  mop  integer3 

|  IF  bool  THEN  integer  ELSE  integer  FI 
|  (  integer  ) 

dop  ::=  SL 

|  SR 

|  IAND 

|  IOR 

|  MOD 
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mop 

+ 

|  INOT 
|  ABS 
|  SQRT 

Bool 

bool 

integer  bopl  integer 
|  bool  bop2  bool 
|  NOT  bool 

bopl 

li 

A  V  A  V  '  II 

II  II  II 

bop2 

::=  AND 

|  OR 

Type 

type 

type  — •  type 

1  typel 

typel 

0 

|  typename 

|  STRING  [  size  ]  typename 
|  [  size  ]  typel 
|  (  typej  , • • • , type*  ) 

Constant 

const 

STRING  [  size  )  constl 
|  [  size  ]  const 

|  constl 

const  1 

constname 

|  enumerated 
|  alt  name  t  const  1 
|  tagname  (  'firstchar  ..  'lastchar  ) 
|  tagname  /  (  lwb  ..  upb  ) 

|  (  constsetj  ,  •••  ,  constsett  ) 

|  ?  typel 
I  typel 
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Constset 

constset 

Unit 

unit 

unitl 


unit2 


fnparams 


params 


attributes 

attname 


constj  •  I  const* 


unit  CONC  unitl 

unit  fnname  fnparams  attributes  unitl 
unitl 

STRING  [  size  ]  unitl 
[  size  ]  unitl 

[  INT  repname  =  lwb  ..  upb  ]  unitl 
fnname  fnparams  attributes  unitl 
altname  &  unitl 
unit2  //  altname 
unit2  attributes 


signalname 
enumerated 
10  signalname 
unit2  [  index  ] 
unit2  [  lwb  ..  upb  ] 
unit2  [[  unit  ]] 

REPLACE  (unit,  unit,  unit) 

IF  bool  THEN  unit  ELSE  unit  FI 

?  typel 

closedclause 

{  paramsj  ,  •  •  •  ,  params*  } 
nullname 


integer 

type 

const 

fnname 

macname  fnparams 


attnamej  •  •  •  attname*.i 


©  attributename 
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Closedclause 

doseddause 


cases 

elsecases 

elseof 

step 


declarations 


decnames 

let decs 
makedecs 

joindecs 

joinunit 


CASE  unit  OF  cases  elsecases  ELSE  unit  ESAC 
CASE  unit  OF  cases  elsecases  ESAC 
0 

(  unitj  ,  •  •  •  ,  unit*  ) 

BEGIN  step*  •  •  •  step*.!  OUTPUT  unit  END 
BEGIN  stepi  •••  step*  END 
(  stepi  •  •  ■  stept.j  OUTPUT  unit  ) 

(  stepi  •  •  •  step*  ) 

BEGIN  SEQ  sequencei  ;  •  •  •  ;  sequence*.!  ;  OUTPUT  unit  END 
BEGIN  SEQ  sequence!  ;  •  •  •  ;  sequence*.!  END 
(  SEQ  sequence!  ;  •  •  • ;  sequence*.!  ;  OUTPUT  unit  ) 

(  SEQ  sequence!  ;  •  •  •  ;  sequence*.!  ) 

constseti  :  uniti  ,  •••  ,  constset*  :  unit* 


elseofi  •  •  •  elseof*. ! 


ELSEOF  cases 


declarations  . 

|  LET  letdecsj  ,  ••  •  ,  letdecs*  . 

|  MAKE  makedecs!  ,  ■  •  •  ,  makedecs*  . 

|  JOIN  joindeesi  ,  •••  ,  joindecs*  . 

|  FOR  multiplejoini  •  •  •  multiplejoin*  JOIN  joindeesi  ,  •  •  •  ,  joindecs,  . 
|  PRINT  printitemi  ,  •  •  •  ,  printitem*  . 

|  FAULT  printitemi  ,  •  •  •  ,  printitem*  . 


INT  intdec!  ,  -  •  •  .  intdec* 

|  TYPE  typedeci  ,  •  •  •  ,  typedec* 

1  CONST  constdeci  ,  •••  ,  constdec* 

|  FN  fndec]  ,  •  •  •  ,  fndec* 

|  MAC  macdeci  ,  •  •  •  ,  macdec* 

signalname 

|  (  sigornullnamei  ,  •  •  •  ,  sigornullname*  ) 

decnames  =  unit 

fnname  fnparams  fnparams  attributes  :  signalname]  •  ■  •  signalname* 
|  [  size  ]  makedecs 

unit  — *  joinunit 

joinunit  CONC  joinunitl 
|  joinunit  1 


78 


Composite  ELLA  Syntax 


joinunitl 

joinunit2 

multiplejoin 

printitem 

sequence 


sequence2 


seqcase 

seqstep 

seqelsecase 

seqelseof 

vardecs 

pvardecs 

assign 


[  INT  repname  =  lwb  ..  upb  ]  joinunitl 
|  joinunit2 

signalname 
|  10  signalname 
|  joinunit2  [  lwb  ..  upb  ] 

|  joinunit2  [  index  ] 

|  (  joinunitl  ,  •  •  •  ,  joinunit*  ) 

INT  repname  =  lwb  ..  upb 

IF  bool  THEN  intorstringi  •  •  •  intorstrmg*  FI 
|  intorstringi  •  •  •  intorstringi 


declarations 

|  LET  letdecsi  ,  •  •  •  ,  letdecs* 

|  VAR  vardecsi  ,  •  ■  •  ,  vardecs* 

|  PVAR  pvardecsi  ,  •  •  •  ,  pvardecs* 

|  PRINT  printitem!  ,  •  •  •  ,  printitem* 

|  FAULT  printitemi  ,  •  •  •  ,  printitem* 

|  sequence2 

assign  :=  unit 

|  (  multassigni  ,  •  •  •  ,  multassign*  )  :=  unit 

|  CASE  unit  OF  seqcase  seqelseof  ELSE  sequence2  ESAC 

|  CASE  unit  OF  seqcase  seqelseof  ESAC 

I  IF  bool  THEN  sequence2  ELSE  sequence2  FI 

|  IF  bool  THEN  sequence2  FI 

|  [  INT  repname  =  lwb  ..  upb  ]  sequence2 

|  (  sequence2i  ;  •  •  •  ;  sequence2*  ) 

seqstepi  ,  •  •  •  ,  seqstep* 

constset  :  sequence2 
|  constset  : 

seqelseofi  •  •  •  seqelseof*. i 
ELSEOF  seqcase 
decnames  :=  unit 
decnames  ::=  const 
signalname 

|  r  -sign  [  lwb  ..  upb  ] 

|  assign  (  index  ] 

|  assign  [[  unit  ]] 
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multassign  = 

Function  Body 
functionbody 


delaybody  ::  = 

i 

samplebodv  = 

I 

fasterbody  ::  = 

I 

slowerbody  ::  = 

! 

Integer  Declaration 
intdec  ::  = 

Type  Declaration 
typedec  ::  = 

typeornew  ::  = 

I 

I 

I 

typealt  ::  = 


assign 

nullname 


unit 

REFORM 

BIOP  biopname  fnparams 

ALIEN  alienname  fnparams 

ARITH  integer 

DELAY  delaybody 

IDELAY  (  initialvalue  ,  delaytime  ) 

SAMPLE  samplebody 

FASTER  fasterbody 

SLOWER  slowerbody 

RAM  (  initialvalue  ) 

IMPORT 


(  initialvalue  ,  ambigtime  ,  ambigvalue  ,  delaytime  ) 
(  initialvalue  ,  ambigtime  ,  delay  time  ) 

(  initialvalue  ,  delaytime  ) 

(  interval  ,  initialvalue  ,  skewtime  ) 

(  interval  ) 

(  fnname  ,  fasttime  ,  initialvalue  ,  skewtime  ) 

(  fnname  ,  fasttime  ) 


(  fnname  ,  slowtime  ,  initialvalue  .  skewtime  ) 
(  fnname  ,  slowtime  ) 


intname  =  integer 


typename  =  typeornew 
type 

NEW  tagname  /  (  lwb  ..  upb  ) 

NEW  (  typealtj  !•••  I  typealt*  ) 

NEW  tagname  (  charangej  I  •  •  •  I  charange*  ) 

altname  &  typel 
altname 
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charange  ::=  'char 

)  'firstchar  ..  'lastchar 

Constant  Declaration 


constdec  constname  =  constset 

Function  Declaration 


fndec 

fnname  =  input  — *  outtype  :  functionbody 

input 

1 

terminals 

0 

terminals 

(  terminaltype!  ,  •  •  •  ,  terminaltype*  ) 

terminaltype 

1 

type  :  sigornullnamej  •  •  •  sigomullname* 
type 

sigomullname 

t 

signalname 

nullname 

outtype 

1 

terminals 

type 

Macro  Declaration 

macdec 

fnname  maclist  =  macinput  — *  outtype  :  functionbody 

maclist 

! 

{  macprami  ,  •  •  •  ,  macpram*  } 
nullname 

macpram 

1 

1 

1 

! 

1 

1 

INT  intnamei  •  •  •  intname* 

TYPE  typenamei  •  •  •  typename* 

CONST  mactype  :  constnamej  •  •  •  constname* 

FN  (  mactype  )  — >  mactype  :  fhnamej  •  •  •  fnname* 

FN  ()  — *  mactype  :  fnnamej  •••  fnname* 

MAC  maclist  (  mactype  )  -♦  type:  fnnamei  •  •  •  fnname* 
MAC  maclist  ()  -*  type:  fhnamej  •••  fnname* 

macinput 

1 

macterminals 

0 

macterminals 

(  mactermtypej,  •  •  •  ,  mactermtype*  ) 
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mactermtype 

•* 

mactype  :  sigornullnamei  •  •  •  sigornullname* 

|  mactype 

mactype 

::= 

mactype  — *  mactype 
|  mactypel 

mactypel 

0 

|  typename 

|  STRING  [  size  ]  typename 
|  (  size  ]  mactypel 
|  (  mactype!  ,  •••  ,  mactype*  ) 

|  mactype2 

mactype2 

::= 

[INT  macintname]  mactype 
|  STRING  [INT  macintname]  typename 
|  TYPE  mactypename 

Imports 

imports 

IMPORTS  importgroup  ,  •  •  •  ,  importgroup 

importgroup 

context  :  importfn  •  •  •  importfn 

importfn 

fnname 

|  fnname  (  RENAMED  fnname  ) 

|  fnname  RENAMED  fnname 

context 

contextname 

|  contextname  /  subregionname 

Closure 

closure 

declarations  •  •  •  declarations 
|  declarations  •  •  •  declarations  imports 
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C  Core  ELLA  Composite  Syntax 

C.l  Basic  Notation 


abc  £  Abe 

‘abc’  is  an  element  of  the  set  ‘Abc’ 

b  ::=  c 

the  syntax  definition  of  lb’  is  ‘c’ 

1 

the  separator  of  alternatives  in  a  syntax  definition 

1 

ELLA  separator  of  alternatives 

di  •  •  -  dfc 

one  or  more  occurrences  of  ‘d’ 

di,  •  •  •  ,  di 

one  or  more  occurrences  of  ‘d’  separated  by 

Note  if  k=l  then  no  *,’  is  present. 

di,  •  •  •  ,  di.i 

zero  or  more  occurrences  of  ‘d’  separated  by 

Note  if  k=0  then  no  is  present. 

Z 

Ni 

{  1,2,-..  } 

Identifier 

Lower  case  letter 

Fnname 

Upper  case  letter  or  symbol 

Constant 

ELLA  constant  expression 

Character 

Any  printable  character 

C.2  Syntactic  Categories 

typename 

€ 

Identifier 

(ELLA  type  name  e.g.  lower  case) 

signalname 

6 

Identifier 

(ELLA  signal  name) 

tagname 

€ 

Identifier 

(ELLA  tagged  type  name) 

altname 

€ 

Identifier 

(ELLA  enumerated  type  alternative) 

fnname 

£ 

Fnname 

(ELLA  function  name  e.g.  upper  case  or  symbol) 

biopname 

€ 

Fnname 

(ELLA  BIOP  name  e.g.  upper  case  ) 

z 

€ 

Z 

(An  integer) 

lwb,  upb 

€ 

Z 

(An  integer) 

€ 

Nj 

(A  non-zero  positive  integer) 

index 

€ 

Ni 

(A  non-zero  positive  integer) 

size 

€ 

Nj 

(A  non-zero  positive  integer) 

interval 

€ 

N, 

(ELLA  timing  interval) 

ambigtime 

£ 

Ni 

(Ambiguity  delay  time) 

delaytime 

£ 

N, 

(delay  time) 

skewtime 

€ 

N» 

(skew  delay) 

initial  value 

t 

Constant 

(Delay,  Retiming  or  Ram  initialisation  value) 

ambigvalue 

£ 

Constant 

(Delay  ambiguity  value) 

char 

€ 

Character 

(A  printable  character  e.g.  ‘a’) 

string 

£ 

String 

(A  string  of  printable  characters  e.g.  ‘abc’) 

£4 
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C.8  Syntactic  Definitions 
Enumerated 


enumerated 


Type 

type 


Constant 

const 


const  1 


Constset 


altname 
|  tagname  /  z 
|  tagname  'char 
|  tagname  "string" 


typename 

|  STRING  [  size  ]  typename 
|  [  size  ]  type 
|  (  type!,  •••,  type*  ) 

I  0 


STRING  [  size  ]  constl 
|  [  size  ]  const 

|  constl 

enumerated 
j  altname  &  constl 
|  (  const],  •  •  •,  const*  ) 

I  ?  type 

I  0 


constset 


const  set  1 


constset2 


constseti  !  •••  I  constset* 

STRING  [  size  J  constset2 
|  [  size  j  constseti 

|  constset2 


enumerated 
|  altname  &  constset2 
|  (  constseti,  •••,  constset*  ) 

I  type 
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Unit 

unit 


unitl 


unit  2 


unit  CONC  unitl 
|  unitl 

STRING  [  size  ]  unitl 
|  [  size  ]  unitl 

|  fnname  unitl 
|  altname  &  unitl 
|  unit2  / /  altname 
|  unit2 

signalname 
|  enumerated 
|  unit2  ( index  ] 

|  unit2  [  index/u,j  ..  indexupj  ] 

|  unit2  [[  unit  ]] 

|  REPLACE  (unit,  unit,  unit) 
I  ■  type 

|  closedclause 


Closedclause 


closedclause 


cases 


CASE  unit  OF  cases  ELSE  unit  ESAC 
!  (  unit],  •  •  •,  unit]..  ) 

1  BEGIN  step]  stepi-  i  OUTPUT  unit  END 

I  0 


constsetj  :  unit],  •  •  •,  constset*  :  unit* 


step  ::=  typedec 

|  fndec 

|  LET  signalname  =  unit  . 

|  MAKE  fnname  :  signalname  . 
|  JOIN  unit  — >  signalname  . 


Function  Body 

functionbody  ::=  unit 

|  REFORM 
|  BIOP  biopname 

|  DELAY  (  initialvalue,  ambigtime,  ambigvalue,  delaytime  ) 
|  IDELAY  (  initialvalue,  delaytime  ) 

|  SAMPLE  (  interval,  initialvalue,  skewtime  ) 

|  RAM  (  initialvalue  ) 
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Type  Declaration 

typedec  ::=  TYPE  typename  =  typeornew. 

typeornew  ::=  type 

|  new 

new  ::=  NEW  tagname  /  (  lwb  ..  upb  ) 

|  NEW  (  typealti  |  •  |  typealt*  ) 

j  NEW  tagname  ( 'char!  !•••  I'char*  ) 

typealt  ::=  altname  k  type 

|  altname 


Function  Declaration 

fndec  ::=  FN  fnname  =  input  — *  type  :  functionbody. 

inPut  ::=  (  type]  :  signalnamej,  •  • type*  :  signalname*  ) 

10 


Closure 

declaration  typedec 

I  fndec 

closure  =  declaration]  •••  declaration* 
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D  Kernel  of  ELLA  Data  Structure 

D.l  Conventions 


abc 

G 

Abc  (ie.  it  is  an  element  of  the  set  Abc) 

Indexer,  Size,  Fnno 

C 

Ni 

Typeno,  Tagno,  Inputno 

c 

Ni 

Signalno,  Ambigtime,  Delaytime 

c 

N, 

Interval,  Skew 

c 

Ni 

Inputtype,  Outputtype 

c 

Type 

Initialvalue,  Ambigvalue 

c 

Const 

Fnname,  Biopname 

c 

Upper  case  identifier  or  operator 

Name,  Signalname 

c 

Lower  case  identifier 

Typename,  Tagname 

c 

Lower  case  identifier 

Lowerbound,  Upperbound 

c 

positive  or  negative  integer 

Character 

c 

printable  character 

D.2  Kernel  Data  Structure 
Enumerated 


Enumerated 

Enum 

|  string (  Typeno  x  TagnoSeq  ) 

Enum 

enum(  Typeno  x  Tagno  ) 

Types 

Type 

typeno(  Typeno  ) 

|  typename(  Typename  x  Type  ) 
|  stringtype(  Size  x  Type  ) 

I  types(  TypeSeq  ) 

|  typevoid 

Constants 

Const  ::=  Enumerated 

|  conststring(  Size  x  Const  ) 

|  consts(  ConstSeq  ) 

|  constascoc(  Enum  x  Const  ) 

|  constquery(  Type  ) 

I  constvoid 
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Constant  Sets 


Constset 


Units 

Unit 


Case 


Enumerated 

constsetalts(  ConstsetSeq  ) 
constsetstring(  Size  x  Constset  ) 
constsets(  ConstsetSeq  ) 
constsetassoc(  Enum  X  Constset  ) 
constsetany(  Type  ) 


Enumerated 

conc(  Unit  x  Unit  x  Outputtype  ) 
unitstring(  Size  x  Unit  ) 
units(  UnitSeq  ) 
instance(  Fnno  x  Unit  ) 
unitassoc(  Enum  x  Unit  ) 
extract  (  Unit  x  Enum  ) 
signal(  Signalno  ) 

index(  Unit  x  Indexer  x  Outputtype  ) 

trim(  Unit  x  Indexer  x  Indexer  x  Outputtype  ) 

dyindex(  Unit  x  Unit  x  Outputtype  ) 

replace(  Unit  x  Unit  x  Unit  ) 

unitquery(  Type  ) 

casedflusej  Unit  x  CaseSeq  x  Unit  ) 

unitvoid 


case(  Constset  x  Unit  ) 


Function  Declarations 


Fndec 

I ;  r 

fndec(  Fnname  x  Inputtype  x  SignaldecSeq  x  Outputtype  x  Fnbody  ) 

Signaldec 

::  = 

signaldec(  Signalname  x  Type  x  Unitorinput  ) 

Unitorinput 

::  = 

Unit 

|  input 

Fnbody 

Unit 

1 

reform 

1 

biop{  Biopname  ) 

1 

delay(  Initialvalue  x  Ambigtime  x  Ambigvalue  x  Delaytime  ) 

1 

idelay(  Initialvalue  x  Delaytime  ) 

1 

sample(  Interval  x  Initialvalue  x  Skew  ) 

1 

ram(  Initialvalue  ) 
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Type  Declarations 

Typedec  ::=  typedec(  Typename  x  New  ) 

New  tags(  TagSeq  ) 

|  ellaint(  Tagname  x  Lowerbound  x  Upperbound  ) 
|  chars  (  Tagname  x  CharacterSeq  ) 

Tag  ::=  tag(  Tagname  x  TypeOpt  ) 

Closures 

Closure  ::=  TypedecSeq  X  FndecSeq 
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E  FIFO  Example 


This  appendix  presents  a  description  of  a  fifo  written  in  high  level  ELLA  together  with  an 
automatically  transformed  version  of  the  circuit. 


E.l  High  Level  Description 

ft  Type  Declarations  ft 

TYPE  bool  «  IEW  (  t  I  f  I  x  ) . 
int  *  IEW  i/(0..100). 


ft  Fifo  -  data  goes  into  the  first  empty  cell.  ft 
ft -  # 


MAC  FIFO  {IHT  size}  =  (int : data.in,  bool: shift.in,  bool: shift.out)  ->  (int,  bool) 
(SEQ 

PVAR  fifo  ::=  [size] (i/0,  f);  ft  create  state  variable  ft 


CASE  shift.out 

OF  t  :  fifo  :=  fifo [2 .. size]  COKC  (i/0,  f)  ft  remove  element 
ESAC; 


VAR  entered  : =  f ; 

CASE  shift.in  #  add  element 

OF  t  :  [1ST  i  =  1.. size-1] 

CASE  (entered,  fifo [i] [2]) 

OF  (f,f)  :  (  fifo[i]  :=  (data.in,  t); 
entered  :  =  t 

) 

ESAC 


ESAC; 


OUTPUT  (fifo  [1]  [1] ,  entered) 

). 


# 


* 


FI  FIF0.9  *  (int:  data.in,  bool:  shift.in,  bool:  shift. out)  ->  (int,  bool): 
FIFO  {9}  (data.in,  shift.in,  shift. out).  ft  call  macro  ft 


E.2  Transformed  Description 

This  section  presents  the  result  of  applying  the  built-in  software  transformations  of  ELLA 
to  the  above  FIFO  circuit.  Note  that  names  which  begin  with  an  ‘s’  followed  by  a  number 
are  automatically  generated  by  the  transformation  process.  Also  function  names  of  the  form 
‘NAME  #  {..}  #’  are  instantiations  of  macros  where  the  items  between  the  hash  comments  are 
the  parameters  which  have  be  used  in  the  instantiation. 
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TYPE  bool  =  IEW(  t  I  f  I  x  ). 
TYPE  int  =  IEW  i/(  0..100  ). 


FI  FI .DELAY  #{[  9  ](  int,  bool  ), 
DELAY (  [  9  3(  i/0,  f  ),  1  ). 


[  9  ](  i/0,  f  )}#«([  9  3(  int,  bool  ))  -> 
[  9  3 (  int ,  bool  ) : 


FI  FIFO  #{9}*  ■  (int:  data.in,  bool:  ahiit.in,  bool:  shift.out)  ->  (int,  bool): 
(  MAKE  FI .DEL AY  #{[  9  3(  int,  bool  ),  [  9  3(  i/0,  f  )}#  :  s6fifo. 

LET  s7fifo  = 

CASE  shilt.out 
OF  t:  (  LET  s8filo  = 

s61ilo[  2.. 9  3  COHC  (  i/0,  1  ). 

OUTPUT  s8f ilo 

) 

ELSE  s6iifo 
ESAC. 

LET  s9entered  =  1 . 

LET  (  fifo,  entered  )  -- 
CASE  shift.in 

OF  t:  (  LET  (  sl2fifo,  sl3entered  )  = 

CASE  (  s9entered,s7f if o [l  3[  2  3  ) 

OF  (  f,f  ):(  LET  sl4fifo  =  (  data.in, t  )  COHC 

s~fifo[2. ,9  ]. 

LET  sl5entered  =  t. 

OUTPUT  (  sl4f if c ,  slSer.tered  ) 

) 

ELSE  (  s7fifo,  s9entered  ) 

ESAC. 

LET  (  slSfifo,  sl7entexed  )  - 

CASE  (  sl3entered,  sl2fifo[2  3t  2  3  ) 

OF  (  f,  f  ):  (LET  sl8fifo  =  (  sl2fifo[l  3  COHC 

(  data.in,  t  ))  COHC 
sl2fifo[3. .9  3 . 

LET  sl9entered  =  t. 

OUTPUT  (  slSfifo,  sl9entered  ) 

) 

ELSE  (  sl2fifo,  sl3entered  ) 

ESAC. 

LET  (  s20fifo,  s21entered  )  - 

CASE  (  sl7entered,  sl€fifo[3  3[  2  3  ) 

OF  (  f,  f  ):  (LET  §22fifo  =  (  sl6fifo[1..2  j  COHC 

(  data.in,  t  ))  COHC 
sl6fifo[4. .9  3 • 

LET  s23entered  =  t. 

OUTPUT  (  s22f if o,  s23entored  ) 

) 

ELSE  (  sl6fifo,  sl7entered  ) 

ESAC. 
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LET  (  s24fifo,  s25entered  )  = 

CASE  (  s21«ntarad,  s20fifo[4  ][  2  ]  ) 

OF  (  f,  f  ):  (LET  s26fifo  =  (  s20fifo[1..3  ]  COBC 

(  data.in,  t  ))  COIC 
«20fifo[5. .9  ] . 

LET  s27antarad  =  t. 

OUTPUT  (  s26fifo,  s27antarad  ) 

) 

ELSE  (  s20fifo,  s21#ntarad  ) 

ESAC. 

LET  (  s28fifo,  s29entarad  )  = 

CASE  (  s25ent«r«d,  s24fifo[5  ][  2  ]  ) 

OF  <  1,  f  ):  (LET  s30fifo  *  (  s24fifo[i..4  ]  COIC 

(  data.in,  t  ))  COBC 
s24fifo[6. .9  ] . 

LET  s31ent«red  =  t. 

OUTPUT  (  s30f if o,  s31entered  ) 

) 

ELSE  (  s24fifo,  s25entered  ) 

ESAC. 

LET  (  s32fifo,  s33entered  )  = 

CASE  (  s29entered,  s28fifo[6  ][  2  ]  ) 

OF  (  f,  f  ):  (LET  s34fifo  =  (  s28fifo[l..5  ]  COBC 

(  data.in,  t  ))  COBC 
s28f if o  [7 . . 9  ] . 

LET  s35enterod  =  t. 

OUTPUT  (  s34f if o,  s35entered  ) 

) 

ELSE  (  s28f if o ,  s29entored  ) 

ESAC. 

LET  (  s36fifo,  s37enter«d  )  = 

CASE  (  s33ent®red,  s32fifo[7  ][  2  ]  ) 

OF  (  f,  f  ):  (LET  s38fifo  =  (  s32fifo[1..6  ]  COBC 

(  data.in,  t  ))  COBC 
s32f if o [8 . . 9  ] . 

LET  s39entered  =  t. 

OUTPUT  (  s38f ifo,  s39«nter«d  ) 

) 

ELSE  (  s32f if o,  s33entered  ) 

ESAC. 

LET  (  s40fifo,  s41antared  )  = 

CASE  (  s37«ntarad,  «36fifo[8  ][  2  ]  ) 

OF  (  f,  f  ):  (LET  s42fifo  =  (  s36fifo[l..7  ]  COBC 

(  data.in,  t  ))  COBC 
s36fifo[9  ] . 

LET  f43antarad  *  t. 

OUTPUT  (  »42fifo,  i43antarad  ) 

) 

ELSE  (  s36f if o ,  s37#ntarad  ) 

ESAC. 
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OUTPUT  (  s40fifo,  s41antared  ) 

) 

ELSE  (  s7Jifo,  s9entered  ) 

ESAC. 

JOII  t ito  ->  s6f ifo. 

OUTPUT  (  fifo[  1  ][  1  ],  entered  ) 

). 

FI  FIF0.9  *  (  iat:  data. in,  bool:  shift.ia,  bool:  shift.out  )  ->  (  int,  bool  ): 
FIFO  #{9}#  (  data.in,  shift.in,  shift.out  ). 


It  can  be  noted  that  the  transformed  function  is  a  valid  description  in  Core  ELLA. 
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F  Three  Pump  Controller 

F.l  Introduction 

This  appendix  presents  a  high  level,  medium  level  and  low  level  description  in  ELLA  of  a  three 
pump  controller.  The  definition  of  the  controller  is  given  in  [Bar91]  and  is  reproduced  here 


A  reservoir  is  connected  to  a  lake  by  a  pipe  line.  Water  is  taken  from  the  lake  to  the  reservoir 
by  a  system  of  three  pumps. 

Three  level  sensors  are  installed  on  the  reservoir.  Their  outputs  are  denoted  by  signals  aj,  02, 
<13.  Signal  Oi  is  0  when  the  water  is  above  level  i,  for  i  =  1,2,3  and  has  a  value  1  when  the 
water  is  below  level  i.  The  number  of  pumps  that  are  on  at  any  one  time  depends  on  the  water 
level  in  the  reservoir.  In  particular:  if  the  water  level  is  between  level  1  and  2,  then  one  pump 
should  be  in  operation;  if  the  water  level  is  between  level  2  and  3,  then  two  pumps  should  be  in 
operation;  if  the  water  level  is  below  level  3,  then  three  pumps  should  be  in  operation.  Of  course, 
if  the  water  level  is  above  level  1  then  no  pumps  should  be  in  operation.  In  order  to  equalise 
wear  on  the  pumps,  they  should  come  into  operation  in  a  cyclic  manner. 


F.2  High  Level  Description 

In  this  section  we  give  a  high  level  description  of  the  pump  controller. 

TYPE  pump  =  HEW  (none  I  a  I  b  I  ab  I  c  1  ca  I  be  I  abc  ) , 
level  =  SEW  1/(0. .3), 
bool  *=  HEW  (t  |  f). 

FH  COHTROL  =  (level: in)  ->  pump: 

(  SEQ 

PVAR  store  ::=  (none.t); 
store  :=  CASE  in  OF 

1/0  :  (store[l] ,t) , 

1/1  :  CASE  store [1]  OF 

a  I  ca  :  (b,f), 
b  I  ab  :  (c,f) 

ELSE  (a ,i) 

ESAC, 

1/2  :  CASE  store  Cl]  OF 

a  I  ab  :  (bc,f), 
b  I  be  :  (ca,f) 

ELSE  (ab,f ) 

ESAC, 

1/3  :  (abe.f) 

ESAC; 

OUTPUT  CASE  store [2]  OF 
t:  none, 

1:  store [1] 

ESAC 

). 
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Three  enumerated  types  have  been  defined.  The  first  ‘pump’  denotes  which  pumps  are  actually 
operating,  the  pumps  being  known  as  ‘a’,  ‘b’  and  ‘c’.  At  first  glance  the  ordering  of  the 
enumerated  type  might  appear  strange.  However  the  ordering  was  chosen  such  that  when  the 
circuit  is  transformed  to  gate  level  the  output  of  the  controller  will  be  a  three  bit  signal,  with 
each  bit  representing  one  of  the  pumps.  The  second  type  ‘level’  denotes  the  level  of  water  in 
the  reservoir,  with  zero  representing  a  full  reservoir.  The  third  type  is  a  boolean  flag  which  is 
used  in  the  monitoring  of  the  active  pump.  The  function  CONTROL  is  the  pump  controller 
and  its  CASE  clause  sets  up  which  pumps  get  switched  on. 

Although  CONTROL  has  been  written  using  sequences  this  is  not  really  necessary.  A  functional 
version  of  CONTROL  is  therefore  given,  this  being  an  equivalent  description  to  the  sequential 
form. 

F«  FI. DELAY  *  ((  pump,  bool  ))  ->  (  pump,  bool  ):  DELAY ( (  none,  t  ),  1  ). 

FI  COVTROL  *  (  level:  in  )  ->  pump: 

BEGI1 

HAKE  Fl. DELAY :  s3store. 

LET  store  = 

CASE  in  OF 

1/0:  (  s3store[  1  3,  t  ), 

1/1: 

CASE  s3store [  1  ]  OF 
a  |  ca:  (  b,  f  ) , 

b  |  ab:  (  c,  f  ) 

ELSE  (  a.  f  ) 

ESAC, 

1/2: 

CASE  s3store[  1  ]  OF 
a  I  ab:  (  be,  f  ), 

b  |  be:  (  ca,  f  ) 

ELSE  (  ab,  f  ) 

ESAC, 

1/3:  (  abc,  f  ) 

ESAC. 

JOII  store  ->  s3store. 

OUTPUT 

CASE  store t  2  ]  OF 
t :  none , 
i:  store [  1  ] 

ESAC 

EID. 


F.S  Medium  Level  Description 

This  section  presents  the  results  of  replacing  the  enumerated  types  for  the  pump  switch’s  and 
level  indicators  by  rows  of  two  valued  types.  This  synthesising  of  the  types  makes  explicit  the 
algorithm  behind  the  type  naming  of  the  high  level  version.  It  would  have  been  possible  to 
describe  the  controller  from  the  medium  level  from  the  outset,  however  the  higher  level  version 
provides  extra  checks.  In  particular  in  the  high  level  version  the  level  indicators  can  only  take 
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four  possible  values  whereas  in  this  medium  level  version  they  can  take  eight.  This  medium  level 
version  treats  such  illegal  values  as  ‘unknown’  and  causes  the  simulator  to  return  the  ELLA 
unknown  value,  whereas  the  high  level  version  would  explicitly  indicate  if  the  level  integer  range 
was  violated. 

This  medium  level  version  has  maintained  close  correspondence  with  the  high  level  version  by 
the  use  of  ‘constant’  statements.  Thus  the  majority  of  the  controller  description  has  remained 
unaltered,  hence  reducing  the  likelihood  of  error.  The  complete  description  is  given  by 

TYPE  Mitch  *  IEV  (on  I  off), 
pump  *  [3] switch, 
level  *  [3] switch, 
bool  «  IEW  (t  I  f). 

CONST  none  *  (off,  off,  off), 
a  *  (on,  off,  off), 

b  *  (off,  on,  off), 

c  *  (off,  off,  on), 

ab  =  (on,  on,  off), 

ca  *  (on,  off,  on), 

be  =  (off,  on,  on), 

abc  =  (on,  on,  on). 

CONST  levelO  =  (off,  off,  off), 
levell  =  (on,  off,  off), 
lev«12  =  (on,  on,  off), 
l«v«13  =  (on,  on,  on). 


FI  CONTROL  =  (level: in)  ->  pump: 

(  SEQ 

PVAR  store  ::=  (none.t); 

store  :=  CASE  in  OF 

levelO  :  (stored]  ,t) , 
levell  :  CASE  stored]  OF 
a  I  ca  :  (b,f), 
b  I  ab  :  (c,f) 
ELSE  (a,f ) 

ESAC, 

level2  :  CASE  store [l]  OF 

a  I  ab  :  (bc,f), 
b  I  be  :  (ca,f) 
ELSE  (ab.f) 

ESAC, 

level3  :  (abc.f) 

ESAC; 

OUTPUT  CASE  store  [2]  OF 
t:  none, 
f:  store  [l] 

ESAC 

). 


A 
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F.4  Low  Level  Description 

This  section  presents  the  results  of  synthesising  the  medium  level  description  of  the  pump 
controller  through  the  ELLA-GATEMA  77  [Pitt88]  system.  Apart  from  the  functions  Fl .DELAY 
and  CONTROL  all  the  other  functions  are  basic  cells  in  one  of  the  technology  libraries  that 
GATEMAP  supports. 

# - - - - - - - * 

*  « 

«  ELLA  netlist  generated  by  GATEMAP  II  version  1.2  « 

*  • 

«  Module  :  COBTROL  t 

«  Date  :  16-MAY-1991  13:41  # 

t  Library  :  USR$W0RK:[]  # 

#  Technology  :  USRJGATEMAPROOT : [12 .TECHHOLOGIES] *******  « 

#  * 

# . - . - . —  - . # 


# . TYPES  - . . . * 

TYPE  bool  =  HEW(  f  I  t  I  x  I  z  ) 

TYPE  tech.bool  =  bool. 

COHST  logic.O  =  f. 


# . - . LIBRARY  CELLS . — . # 

FI  IIV1  =  (  bool:  a  )  ->  bool:  $  Inverter  #. 

FI  IAID2  =  (  bool:  a  b  )  ->  bool:  #  Two  Input  IABD  $ 

FI  IAID3  -  (  bool:  a  b  c  )  ->  bool:  #  Three  Input  IAID  # 

FI  I0R2  -  (  bool:  a  b  )  ->  bool:  #  Teo  Input  I0R  • 

FI  I0R3  •  (  bool:  a  b  c  )  ->  bool:  *  Three  Input  I0R  # 

FI  X2AI0R  ■  (  bool:  a  b  c  d  )  ->  bool:  I0R(AID(a,b) ,  AID(c.d)). 

FI  EXIOR  »  (  bool:  a  b  )  ->  bool:  •  Two  Input  Exclusive  OR  • 

FI  CLKB  ■  (  bool:  ai  )  ->  (  bool,  bool  ):  f  Clock  Drvier  # 

FI  DF  ■  (  bool:  ckt  cki  d  )  ->  (  bool,  bool  ):  #  Clocked  Cell  # 
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« . ELLA  DELAY  FU1CTI0S . » 

FI  Fl.DELAY  =  (  tech.bool:  unnamed.input.l ,  tech.bool:  unnamed_input_2, 

tech.bool:  unnamed. input. 3 ,  tech.bool:  unnamed. input. 4  )  -> 

(  tech.bool,  tech.bool,  tech.bool,  tech.bool  ): 

BEGIN 

MAKE  DF  :  xcmpl7  xcmpl9  xcmplS  xcmp21, 

CLKB:  xcmpl8. 

JOIV  (  xcmpl8[  1  ],  xcmpl8[  2  ],  unnamed. input .3  )  ->  xcmpl7, 

(  xcmpl8[  1  3,  xcmplS [  2  ],  unnamed. input .2  )  ->  xcmpl9, 

(  logic. 0  )  ->  xcmpl8, 

(  xcmpl8[  1  ],  xcmpl8[  2  3,  unnamed. input .1  )  ->  xcmpl5, 

(  xcmplSC  1  ],  xcmpl8[  2  ],  unnamed. input .4  )  ->  xcmp21. 

OUTPUT  (  xcmpl5[  1  ],  xcmpl9[  1  ],  xcmpl7[  1  ],  xcmp21[  1  ]  ) 

EID. 

* . PUMP  CONTROLLER . . . . # 

FI  CONTROL  *  (  tech.bool:  in.l,  tech.bool:  in_2,  tech.bool:  in_3  )  -> 

(  tech.bool,  tech.bool,  tech.bool  ): 

BEGIN 

MAKE  INV1  :  xcmp39  xcmp69  xcmp76  xcmp24  xcmp74  xcmp33  xcmp61  xcmp37, 

NAND2  :  xcmp56  xcmp66  xemp25  xcmp36  xcmp38  xcmpS3  xcmp70 

xcmp47  xcmp64, 

NAND3  :  xcmp45  xcmp67  xcmp84  xcmp35, 

N0R3  :  xcmp75  xcmp40  xcmp80, 

X2AN0R  :  xcmp78  xcmp72  xcmp82, 

EXNOR  :  xcmp48 , 

Fl.DELAY:  xcmp4. 

JOIN  (  xcmp72 ,  xcmp67  )  ->  xcmp56, 

(  xcmp37,  in_2,  xcmp47  )  ->  xcmp45, 

(  xcmp56  )  ->  xcmp39, 

(  xcxnp76,  xcmp4[  1  ],  xcmp74  )  ->  xcmp75, 

(  xcmp37,  in_2,  xcmp66  )  ->  xcmp35, 

(  in.l,  xcmp4[  2  ],  xcmp37,  xcmp80  )  ->  xcmp78, 

(  xcmp61 ,  xcmp4[  2  ]  )  ->  xcmp66, 

(  in.l,  xcmp4[  1  ],  xcmp37,  xcmp75  )  ->  xcmp72, 

(  xcmp53  )  ->  xcmp69, 

(  in_2,  xcmp4[  1  3,  xcmp4[  3  ]  )  ->  xcmp40, 

(  in.3  )  ->  xcmp76, 

(  xcmp24 ,  xcmp37  )  ->  xcmp25, 

C  in.l,  xcmp4 [  3  3,  in_3,  xcmp48  )  ->  xcmp82, 

(  xcmp78,  xcmp35  )  ->  xcmp36, 

(  xcmp37,  in.2,  xcmp64  )  ->  xcmp67, 

(  xcmp39,  xcmp37  )  ->  xcmp38, 

(  xcmp37,  xcmp4[  1  3,  xcmp4[  2  3  )  ->  xcmp84, 

(  xcmp36  )  ->  xcmp24, 

<  xcmp4[  3  3  )  ->  xcmp74, 

(  xcmp4[  2  3  )  ->  xcmp33, 

(  xcmp4[  1  3  )  ->  xcmp6i. 
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(  xcmp82,  xcmp45  )  ->  xcmp53, 

(  in.l  )  ->  xcmp37, 

(  xcmp69,  xcmp37  )  ->  xcmp70, 

(  xcmp33,  xcmp4[  3  ]  )  ->  xcmp47, 

(  xcmp66,  xcmp47  )  ->  xcmp64, 

(  xcmp76,  xcmp61,  xcmp4[  2  ]  )  ->  xcmp80, 

(  xcmp40,  xcmp84  )  ->  xcmp48, 

(  xcmp56,  xcmp36,  xcmp53,  xcmp37  )  ->  xcmp4. 

OUTPUT  (  xcmp38,  xcmp25,  xcmp70  ) 


EID. 
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